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Guide  to  CASE  Adoption 


Abstract:  In  an  attempt  to  address  the  productivity  and  quality  problems 
afflicting  the  software  industry,  many  organizations  are  turning  toward 
computer-aided  software  engineering  (CASE)  technology  as  a  potential 
solution.  Unfortunately,  the  inflated  claims  of  vendors  and  unreasonable 
expectations  of  new  users  have  ied  to  many  failed  CASE  adoption  efforts.  This 
guide  answers  questions  organizations  may  have  concerning  CASE 
technology,  and  provides  a  strategy  for  the  adoption  of  CASE  tools  into  an 
organization. 


1  Introduction 

The  software  problem  is  not  new,  nor  is  it  about  to  be  solved.  The  SEI  software  capacity  study 
[Siegel,  Stewman,  Konda.  Larkey,  &  Wagner.  1990]  has  documented  the  critical  software 
needs  facing  the  United  States  military  over  the  next  several  decades.  The  software  demands 
of  the  commercial  sector  are  similar.  Indicators  of  the  existing  software  capacity  problems  in¬ 
clude: 

•  insufficient  resources  to  develop  software  that  is  currently  projected,  leading 
to  a  search  for  greater  productivity. 

•  Problems  In  existing  software,  resulting  in  a  search  for  better  quality  of 
delivered  software  and  an  increased  demand  for  assurance  that 
requirements  are  clearly  stated  and  implemented. 

•  Large  costs  in  the  maintenance  of  existing  software,  resulting  In  a  need  for 
tools  to  restructure  code,  generate  clear  documentation,  and  manage 
multiple  configurations  of  software. 

These  probiems  have  encouraged  a  search  for  new  methods  and  tools  for  developing  soft¬ 
ware  more  effectively.  Computer  Aided  Software  Engineering  (CASE)  tools  represent  a  prom¬ 
ising  technology  which  may  eventually  allow  us  to  address  some  of  our  deficiencies  in  building 
software. 

Unfortunately,  when  CASE  tools  were  first  introduced,  a  number  of  inflated  claims  led  people 
to  believe  that  CASE  tools  would  be  an  immediate  and  primary  solution  to  the  many  problems 
in  developing  and  maintaining  software.  While  such  claims  continue  to  be  common,  the  cumu¬ 
lative  experience  of  CASE  tool  users  is  sobering.  However,  this  experience  may  provide  us 
with  the  data  to  sort  out  the  many  ^and  often  conflicting)  claims. 

1 .1  Purpose  of  This  Guide 

This  guide  is  intended  to  help  project  managers  make  informed  decisions  about  various  CASE 
claims,  and  additionally  to  support  them  in  decisions  concerning  when  and  how  to  introduce 
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CASE  technology  into  an  organization.  The  guide  identifies  some  major  areas  of  concern,  pro¬ 
vides  guidance  for  addressing  these  issues,  and  identifies  sources  for  additional  information. 

The  views  presented  in  this  guide  are  derived  from  interviews  with  managers  in  organizations 
that  have  adopted  CASE  technology,  from  workshops  sponsored  by  the  SEI,  from  our  own  ex¬ 
perience.  from  the  work  of  others  at  the  SEI,  and  from  a  review  of  the  published  literature  con¬ 
cerning  CASE  technology.  The  ideas  and  concepts  presented  are  derived  from  a  number  of 
disciplines  including  software  engineering,  management  science,  and  the  social  sciences. 

The  intent  is  that  this  is  a  "living"  guide  that  evolves  over  time  due  to  changing  technology, 
feedback  from  users  of  this  guide,  and  as  our  understanding  and  perspectives  on  the  issues 
change.  Periodic  republication  of  this  guide  is  planned.  As  a  result,  feecft>ack,  comments,  and 
suggestions  for  improvements  to  this  guide  are  most  welcome. 

1 .2  Organization  of  This  Guide 

This  guide  provides  information  at  several  levels  of  detail  for  individuals  with  varying  informa¬ 
tion  needs.  It  is  not  expected  that  everyone  will  need  or  want  to  read  the  entire  guide.  For  high 
level  managers,  Section  2  offers  an  executive  overview  of  the  major  issues  covered.  A  more 
in-depth  understanding  of  CASE  issues,  and  answers  to  commonly  asked  questions  concern¬ 
ing  CASE  technology,  are  provided  in  Section  3.  Finally,  Section  4  draws  from  the  work  of  ex¬ 
perts  in  the  fields  of  technology  transition  and  CASE  tools  to  define  a  strategy  for  adopting 
CASE  technology. 
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2  Executive  Overvievi 


Because  of  the  nature  of  the  software  problem,  many  organizations  are  attempting  to  increase 
the  productivity  and  quaiity  of  their  software  development  efforts.  Some  have  turned  to  CASE 
tools  as  an  aid  in  developing  better  software.  Initially.  CASE  tools  were  hailed  as  a  panacea 
for  software  development  problems,  with  the  assumption  that  the  use  of  tools  would  by  them¬ 
selves  produce  dramatic  increases  in  productivity.  Recently,  there  has  been  a  recognition  that 
tools  represent  only  one  factor  in  the  improvement  of  software  development  efforts. 

This  guide  addresses  many  of  the  concerns  of  managers  in  the  formulation  of  a  CASE  strate¬ 
gy.  It  identifies  the  different  types  of  CASE  tools  and  the  role  of  tools  within  the  context  of  the 
software  development  process,  the  methods  used  within  an  organization,  the  hardware  and 
software  environment,  and  the  personnel  who  will  use  and  maintain  the  system.  A  number  of 
technical  issues  are  highlighted  including  tool  integration,  data  management,  performance, 
maintainability,  and  standardization.  In  addition,  non-technical  issues  of  relevance  to  manag¬ 
ers  are  considered  including  the  tool  selection,  the  adoption  process,  and  culture  change. 
Each  of  these  issues  represents  an  important  consideration  in  the  formulation  of  a  CASE  strat¬ 
egy- 


2.1  Origins  of  “CASE” 

The  term  Computer  Aided  Software  Engineering  was  first  applied  to  tools  which  provided  sup¬ 
port  for  the  analysis  and  design  phases  of  the  software  development  cycle.  Many  of  the  early 
tools  automated  structured  methods  that  had  been  available  but  were  infrequently  used  due 
in  part  to  the  lack  of  automated  support. 

Later,  there  emerged  other  categories  of  tools  providing  automated  support  for  software  engi¬ 
neering.  The  acronym  CASE  was  applied  to  the  wider  range  of  tools.  Currently  the  vision  of 
CASE  is  that  of  an  interrelated  set  of  tools  which  support  all  aspects  of  the  software  develop¬ 
ment  process.  These  include  tools  which  support  specific  phases  of  the  life  cycle,  such  as 
analysis  and  design  tools,  code  generators,  and  testing  tools;  and  tools  which  provide  func¬ 
tionality  across  the  life  cycle,  such  as  project  management  tools,  configuration  management 
tools,  and  documentation  tools. 

We  use  the  term  CASE  here  to  refer  to  this  wider  range  of  interrelated  tools  that  support  the 
software  engineering  process.  Where  data  is  specific  to  a  particular  type  of  tool,  we  have  iden¬ 
tified  that  type. 

2.2  Impact  of  CASE  Tools 

it  is  imprecise  to  make  blanket  statements  about  the  benefits  of  CASE  technology  due  to  the 
diverse  nature  of  CASE  tools.  Some  tools,  such  as  configuration  management  tools  and  doc¬ 
umentation  tools,  are  generally  accepted  mechanisms  for  improving  the  manner  in  which  soft¬ 
ware  is  developed.  More  controversial  are  the  benefits  of  other  tools,  such  as  the  many 
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analysis  and  design  tools,  reverse  engineering,  or  code  generation  tools  which  are  commer¬ 
cially  available.  Among  the  major  problems  with  careful  measurement  of  the  impact  of  any  type 
of  CASE  tool  are; 

•  The  wide  variation  in  quality  and  value  within  a  single  type  of  tool. 

•  The  relatively  short  time  that  many  types  of  CASE  tools  have  been  in  use  in 
organizations. 

•  The  wide  difference  in  the  adoption  practices  of  various  organizations. 

•  The  general  lack  of  detailed  metric  data  for  previous  and  current  projects. 

•  The  wide  range  of  project  domains. 

•  The  confounding  impact  of  changes  to  methods  and  processes  that  are  often 
associated  with  the  adoption  of  CASE  tools. 

•  The  potential  bias  of  organizations  reporting  CASE  gains  or  losses. 

Illustrative  of  the  problem  with  measuring  CASE  impact  are  the  varying  experiences  of  orga¬ 
nizations  that  have  purchased  and  used  CASE  analysis  and  design  tools.  A  review  of  the  lit¬ 
erature  indicates  that  many  industry  analysts  document  productivity  gains  ranging  from  10% 
to  30%  resulting  from  CASE  analysis  and  design  tool  usage,  with  similar  modest  gains  in  soft¬ 
ware  quaiity  and  documentation.  However,  negative  impact  has  also  been  experienced,  al¬ 
though  documented  publicly  less  frequently.  These  figures  are  derived  primarily  from 
anecdotal  data,  and  therefore  suffer  from  potent!^  “biases”  either  toward  or  against  the  tool. 

A  review  of  the  literature  aiso  indicates  that  tiie  data  gathered  and  effects  of  CASE  tools  ex¬ 
perienced  varies  widely  among  organizations.  Measurement  differences  appear  both  in  the 
manner  in  which  productivity  and  quality  are  measured  and  in  the  quality  of  the  data  gathered. 
Organizations  have  experienced  variances  in  the  impact  of  CASE  tools  depending  on  project 
size,  customer  involvement,  and  user  sophistication.  In  addition,  some  CASE  analysts  expect 
that  true  gain  is  only  realized  after  1-2  years  of  experience,  while  others  suggest  that  the  im¬ 
pact  may  only  become  evident  during  the  maintenance  phase  of  the  software  lifecycle,  where 
improved  software  design  reportedly  attributable  to  CASE  technology  leads  to  lower  mainte¬ 
nance  costs. 

The  most  consistent  benefits  cited  in  the  CASE  literature  are  improved  communications  and 
documentation.  Communications  appears  to  be  enhanced  both  between  the  project  engineers 
and  the  customer  and  among  engineers  working  on  a  project.  The  improvement  is  often  attrib¬ 
uted  to  more  accurate,  consistent,  and  understandable  representations  of  a  system  which  are 
potentially  possible  with  CASE  tools.  The  experienced  improvement  in  documentation  relates 
to  this  greater  consistency  and  accuracy  for  spedfying  the  system  and  to  the  direct  generation 
of  portions  of  the  documentation  by  the  CASE  tools.  Such  documentation  capabilities  may  be 
particularly  important  in  the  government  sector  where  documentation  costs  can  comprise  up 
to  40%  of  project  cost.  However,  experienced  users  of  CASE  tools  reject  the  extravagant  doc¬ 
umentation  claims  made  by  some  CASE  vendors  and  suggest  tiiat  large  portions  of  the  doc¬ 
umentation  process  remain  manual. 
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2.3  Major  CASE  Issues 

Clearly,  the  decision  to  invest  in  CASE  technology  is  not  easy  to  make.  An  organaation  must 
make  informed  assessments  about  the  value  of  a  wide  variety  of  individual  tools  based  on  in¬ 
conclusive  data.  Determining  the  potential  value  of  a  tool  Is  made  even  more  difficult  to  mea¬ 
sure  in  isolation,  since  an  increasing  number  of  CASE  researchers  and  users  have  reached 
the  conclusion  that  the  greatest  value  of  CASE  tools  will  only  be  achieved  when  used  in  con¬ 
cert  with  other  tools  (i.e.,  integrated). 

Organizations  that  are  attempting  to  reach  consensus  on  the  purchase  of  CASE  tools  must 
address  a  number  of  issues.  The  positions  adopted  by  an  organization  can  detennine  whether 
a  CASE  tool  will  be  ultimately  successful.  Among  the  more  vexing  issues  are: 

•  Investment  of  Resources.  The  cost  of  adopting  CASE  technology. 

•  Current  Processes  and  Methods.The  frequently  inexact  match  between 
the  processes  and  methods  supported  by  CASE  tools  and  those  utilized 
within  the  organization. 

•  Support  Mechanisms.  The  extensive  support  systems  necessary  for  CASE 
tools. 

•  Tool  Scalability.  The  somewhat  limited  capabilities  of  CASE  tools  to  deal 
with  very  large  systems. 

•  Assessment  of  Real  Value.  The  difficulty  in  determining  the  actual  value  of 
CASE  tools  when  faced  with  sometimes  inflated  claims  from  vendors. 

•  Standards  Selection.  Selecting  among  the  sometimes  competing  and 
conflicting  standards  supported  by  CASE  tools. 

•  Adoption  Complexity.  The  complexity  of  the  tool  adoption  process. 

These  issues  and  others  are  addressed  In  Section  3. 

2.4  Making  an  Informed  Decision 

Although  empirical  data  to  objectively  analyze  the  impact  of  CASE  tools  on  software  develop¬ 
ment  is  limited,  a  survey  of  the  (primarily)  anecdotal  data  available  indicates  a  consistent  clus¬ 
tering  of  benefits  attributed  to  CASE  technology.  A  list  of  these  commonly  cited  benefits 
includes: 

•  variable  productivity  gains 

•  modest  quality  gains 

•  improved  documentation 

•  enhanced  project  communications 

•  enforcement  of  project  methodology  and  standards 

However,  any  decision  to  bring  a  CASE  tool  into  an  organization  should  be  made  with  an 
awareness  of  both  short-term  and  long-term  implications  of  tool  adoption.  Over  the  short  term, 
organizations  adopting  CASE  tools  should  be  willing  to  accept: 
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•  a  potential  decrease  in  productivity 

•  dissatisfaction  on  the  part  of  employees  adopting  the  new  technology 

•  (Ganges  to  r^^ocess  and  methods 

•  potentially  extensive  training 

•  significant  expense 

Over  the  longer  term,  CASE  organizations  must  address: 

•  Long  term  maintenance  costs  of  CASE  tools  (potentially  for  the  life  cycle  of 
systems  developed  with  the  tool). 

•  Frequent  releases  of  new  technology. 

•  The  potential  that  development  of  environment/tool  frameworks  such  as 
PCTE  will  lead  to  major  restructuring  of  tools. 

•  Continual  costs  for  training  new  staff  and  upgrading  the  skills  of  existing  staff. 

The  success  or  failure  of  a  CASE  adoption  effort  depends  largely  on  the  ability  of  an  organi¬ 
zation  to  manage  short-  and  long-term  costs.  Organizations  which  have  addressed  these 
problems  in  a  well  conceived  adoption  process  stand  the  best  chance  of  success.  This  ap¬ 
proach  contrasts  with  others  which  focus  primarily  on  the  mechanics  of  choosing  a  particular 
tool. 

The  SEI  is  developing  an  outline  of  a  CASE  adoption  process  which  addresses  these  and 
other  concerns.  [Tomatzky  &  Fleischer.  1990]  outlined  the  stages  of  incorporating  a  new  tool 
or  practice  as  a  variant  of  a  pattern:  awareness-problems,  matching-selection,  adoption- 
commitment,  implementation,  and  routinization.  We  have  used  the  stages  of  Tomatzky  and 
Fleischer  as  a  foundation,  and  modified  them  specifically  for  CASE  technology.  The  resulting 
model  postulates  six  stages  for  the  CASE  adoption  process:  awareness,  commitment, 
selection,  trial  implementation,  implementation  strategy,  and  routinization.  These  stages, 
illustrated  in  Figure  2-1,  represent  a  cycle  where  each  stage  provides  the  input  for  the  next. 
Depending  on  the  maturity  of  an  organization  prior  to  the  adoption  effort,  some  of  the 
preliminary  stages  may  have  already  been  completed. 
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Figure  2*1  CASE  Adoption  Stages 


2.4.1  Awareness  and  Commitment 

Most  organizations  perform  a  preliminary  search  for  information  about  CASE  tools  long  before 
they  have  made  any  commitment  to  adopt  CASE  technology.  During  this  awareness  phase,  it 
is  useful  to  become  versed  in  CASE  literature,  attend  workshops  and  seminars,  and  solicit  in¬ 
formation  from  other  organizations  which  have  adopted  CASE  technology.  Experience  at  SEI 
CASE  workshops  suggests  that  perhaps  50%  of  the  attendees  are  involved  primarily  to  be¬ 
come  aware  of  strengths  and  weaknesses  of  CASE  technology. 

The  commitment  stage  consists  of  the  decision  process  to  adopt  CASE  tools.  Commitments 
from  both  management  and  those  who  will  be  utilizing,  or  otherwise  impacted  by  the  tool  are 
essential.  A  common  mistake  in  this  phase  is  to  diminish  the  importance  of  commitment  from 
the  managers,  engineers  and  support  personnel  whose  daily  activities  will  be  affected  by  the 
incorporation  of  a  new  tool  technology. 

Ironically,  because  management  is  reluctant  to  disrupt  current  practice  to  introduce  the  orga¬ 
nizational  changes  required  for  the  successful  implementation  of  CASE,  it  often  represents  the 
greatest  barrier  to  increased  software  productivity  [Forte,  1988].  The  easiest  way  to  convince 
management  to  dedicate  resources  for  change  is  to  prove  that  substantial  gains  in  productivity 
and  quality  can  be  achieved  by  implementing  CASE  technology.  Unfortunately,  this  evidence 
is  not  readily  available.  Other  methods  of  increasing  the  commitment  of  management  include 
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developing  precise  definitions  about  the  change  and  the  methods  of  measuring  it,  provicfing 
education  about  the  need  for  tool  support,  and  establishing  common  goals  and  objectives  for 
the  project. 

2.4.2  Selection 

While  CASE  tools  can  be  (and  often  have  been)  purchased  in  isolation,  a  more  effective  ap¬ 
proach  to  the  selection  process  requires  the  development  of  a  tool  strategy.  The  strategy 
should  address  both  the  short-  and  long-term  needs  of  the  organization,  based  on  overall  pro¬ 
cess  and  technology  improvement  directions. 

Based  on  the  needs  identified  in  a  tool  strategy,  the  choice  of  an  individual  tool  can  begin.  An 
appropriate  tool  selection  approach  includes: 

•  narrowing  down  the  list  of  available  tool  options  to  a  small  number  of  tools, 

•  determining  how  the  new  tool  will  interact  with  other  tools  in  the  environment, 

•  analyzing  candidate  tools  according  to  both  technical  and  non-technical 
criteria,  and 

•  testing  the  candidate  tools. 

2.4.3  Trial  (Implementation) 

Once  a  tool  has  been  tentatively  selected,  it  is  Important  to  try  out  the  tool  on  a  pilot  project. 
Many  organizations  skip  this  step,  as  it  entails  devoting  significant  resources,  including  per¬ 
sonnel,  time,  and  money.  However,  only  a  pilot  project,  carried  out  under  actual  conditions, 
will  determine  what  the  tool  offers,  how  it  works,  how  effectively  it  performs  its  task,  and  its 
shortcomings.  These  issues  are  simply  too  comf^ex  to  make  an  informed  decision  without  a 
trial  evaluation.  Vendor  demonstrations  can  be  helpful,  but  are  not  sufficient  for  making  in¬ 
formed  decisions.  Although  most  vendors  will  make  a  copy  at  little  or  no  cost,  organizations 
must  ensure  that  the  in-house  evaluation  is  realistic.  Tools  best  demonstrate  their  true  capa¬ 
bilities  with  real  data  and  not  in  the  contrived  environment  of  a  vendor’s  tutorial. 

If  management  sees  that  the  tool  aids  the  development  process  during  a  pilot  project,  they 
may  support  its  continued  use.  When  pilot  projects  fail  to  show  performance  or  quality  gains 
immediately,  management  may  grow  discouraged.  However,  even  a  successful  pilot  project 
can  increase  risk  by  raising  management  expectations  that  the  (unrealistically)  positive  results 
will  transfer  directly  to  the  larger  organization.  For  these  reasons,  management  must  be  clear¬ 
ly  informed  and  hold  realistic  expectations  for  success  for  the  pilot  project  and  for  transition  of 
the  new  technology. 

During  the  hands-on  testing  period,  it  will  be  important  to  perfomn  an  ot^ective  analysis  through 
a  fuil  development  cycle,  with  realistic  simulations  of  database  size  and  multiple  users.  This 
type  of  hands-on  testing  wiii  give  a  better  idea  of  the  specific  functions  provided  by  individual 
tools  and  how  various  toois  wiii  work  together. 
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Proper  implementation  of  CASE  tools  can  lead  to  better  quality  software.  Finding  the  best  way 
to  use  these  tools  however,  is  a  difficult  process.  Starting  with  small  pilot  projects  can  make 
implementing  large-scale  efforts  much  easier  later  on.  This  early  work  needs  adequate  staffing 
and  appropriate  leadership,  along  with  the  resources  necessary  to  develop  standards  for  staff 
training  and  tool  operation.  According  to  vendors  and  users  alike,  at  least  one  successful  pilot 
project  demonstrating  CASE  capabilities  is  the  best  way  to  secure  organizational  commitment 
[Feuche.  1989].  Also,  such  a  pilot  project  can  highlight  tool  capabilities.  lesKj  to  the  develop¬ 
ment  of  tool  standards,  and  provide  a  head  start  on  the  construction  of  reusable  component 
libraries. 

2.4.4  Implementation  Strategy 

The  primary  challenge  for  migrating  a  CASE  tool  into  general  use  involves  integrating  the  new 
tool  into  the  existing  environment  while  minimizing  (or  at  least  managing)  the  organizational 
disruption.  The  disruption  of  a  new  tool  can  effect  many  elements  of  the  environment,  including 
the  personnel  and  the  existing  process  and  methods. 

The  problems  of  implementing  a  new  tool  are  similar  to  those  caused  by  the  adoption  of  many 
other  new  technologies.  Effected  personnel  are  often  ambivalent  and  occasionally  negative 
about  the  change,  and  may  need  to  be  reassured  about  their  role  in  the  organization.  The 
characteristics  of  the  tool  may  require  processes  and  methods  be  modified.  The  tool  itself  may 
require  customization  to  support  organizational  needs. 

Poor  implementation  strategies  often  lead  to  the  shelving  of  the  tool.  There  are  many  stories 
telling  of  hundreds  of  copies  of  a  tool  gathering  dust.  It  is  important  to  recognize  that  the  task 
of  implementing  a  tool  is  not  completed  by  careful  selection  of  the  tool  and  the  subsequent 
demonstration  of  tool  capabilities  on  a  pilot  project.  It  also  should  be  recognized  that  mandat¬ 
ing  the  use  of  a  tool  can  be  counter-productive.  An  good  implementation  strategy  is  one  that 
encourages  tool  use  by  rewarding  individuals  and  projects  that  "make  it  work.” 

2.4.5  Routinization 

It  is  frequently  stated  that  software  maintenance  is  the  longest  and  most  expensive  phase  of 
the  software  lifecycle.  For  a  successful  and  cost  effective  maintenance  process,  an  infrastruc¬ 
ture  should  be  built  to  facilitate  incorporation  of  periodic  upgrades,  provide  training,  and  sup¬ 
port  corporate  decisions  concerning  new  directions.  Routinization  of  tool  use  marks  the 
beginning  of  the  maintenance  phase  for  a  CASE  tool.  A  number  of  efforts  to  adopt  tools  have 
failed  because  of  an  inability  to  incorporate  the  tool  into  the  day  to  day  activities  and  planning 
of  the  organization. 

Major  challenges  of  a  CASE  tool  routine  inciude  the  indoctrination  of  new  employees  into  the 
system  and  the  continual  upgrading  of  skills  of  existing  employees.  A  common  mistake  is  to 
provide  initial  training  for  a  group  of  early  users,  followed  by  only  minimal  ongoing  training.  Un¬ 
fortunately,  it  is  the  larger  group  of  users  who  are  not  CASE  tool  "pioneers"  who  potentially 
require  more  training. 
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Another  common  mistake  is  to  underestimate  the  resources  necessary  to  support  continual 
use  of  complex  CASE  tools.  One  factor  that  adds  to  resource  demands  is  the  complexity  of 
the  tool.  Many  CASE  tools  require  experienced  personnel  capable  of  managing  the  tool  data¬ 
bases  and  responding  to  problems.  A  second  factor  involves  the  frequent  release  schedules 
of  CASE  tools.  While  many  of  the  tools  have  matured  to  the  point  where  data  incompatibility 
problems  between  versions  are  minimized,  dependencies  on  the  rest  of  the  computing  envi¬ 
ronment  (such  as  the  operating  system  version)  can  cause  configuration  nightmares. 

Section  4  of  this  guide  contains  a  proposed  CASE  adoption  strategy  based  on  the  CASE  adop¬ 
tion  model,  and  on  the  technology  transition  work  of  others  (including  [Tomatzky  &  Fleischer, 
1990]  and  [Przybylinskl,  Fowler,  &  Maher,  1991]).  Guidance  is  provided  on  assessing  an  or¬ 
ganizations  readiness  to  adopt  CASE  technology  and  Improving  the  selection,  implementa¬ 
tion,  and  routinization  processes. 
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3  Common  CASE  Questions  and  Answers 


Members  of  the  CASE  Technology  Project  at  the  Software  Engineering  Institute  are  frequently 
approached  by  organizations  considering  the  adoption  of  CASE  tools.  These  organizations 
have  very  similar  questions  concerning  CASE  tools  and  CASE  tool  adoption.  This  is  not  sur¬ 
prising,  because  most  organizations  are  struggling  with  similar  difficulties  in  generating  and 
maintaining  software. 

Subsequent  sections  of  this  guide  will  be  devoted  to  identifying  and  answering  some  of  these 
frequently  asked  questions  about  CASE  technology.  The  views  presented  in  this  guide  are  de¬ 
rived  from  interviews  with  managers  in  organizations  that  have  adopted  CASE  technology, 
from  workshops  sponsored  by  the  SEI,  from  our  own  experience,  from  the  work  of  others  at 
the  SEI,  and  from  a  review  of  the  published  literature  concerning  CASE  technology. 


3.1  Should  I  purchase  CASE  tools?  Which  ones? 

Some  organizations  have  benefited  from  CASE  tool  installation,  while  others  have  gained  little 
from  the  considerable  expense.  Because  most  tool  vendors  have  both  satisfied  and  unsatis¬ 
fied  customers,  the  diverse  range  of  values  returned  on  CASE  tool  investment  is  not  due  solely 
to  individual  differences  in  tools. 

Instead,  some  of  the  differences  depend  on  the  characteristics  of  the  adopting  organization. 
In  order  to  predict  the  value  of  a  CASE  tool,  these  characteristics  need  careful  analysis: 

•  Personnel  Factors.  These  Include  tangible  factors  such  as  the  as  the 
willingness  of  personnel  to  change.  [Andrews,  1989]  suggests  that  junior 
engineers  were  more  willing  to  adopt  a  new  technology,  while  experienced 
engineers  were  more  likely  to  resist  the  introduction  of  CASE  tools  and  new 
development  methodologies.  In  general,  a  policy  which  offers  few  surprises 
is  often  best. 

•  Computing  Resources.  Within  an  organization,  the  computing  resources 
can  influence  the  value  derived  from  a  tool  purchase.  Buying  a  tool  may 
require  the  purchase  of  new  hardware  as  well.  Conversely,  insufficient 
computer  resources  (e.g.,  inadequate  CPU,  disk  and  network  capacity)  can 
severely  affect  the  performance  of  CASE  tools.  Also,  some  CASE  tools 
require  substantial  support  from  personnel  to  manage  access  lists  and 
licenses,  and  to  maintain  contact  with  the  vendor. 

•  Organizational  Sophistication.  A  more  sophisticated  organization  requires 
greater  formal  accounting  of  the  software  process.  Thus,  they  will  likely 
benefit  from  the  purchase  of  CASE  tools.  Likewise,  the  stability  of  their 
process  puts  them  in  a  better  position  to  recoup  the  initial  expense  of  CASE 
tools.  A  reasonable  starting  point  for  determining  an  organization's 
sophistication  is  the  SEI  capability  maturity  model  (CMM)  for  software  [Paulk 
etal.,  1991]. 
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•  Organizational  Needs.  Both  perceived  and  actual  needs  can  influence 
considerably  the  types  of  tools  that  are  appropriate,  the  adoption  process 
necessary,  and  the  kinds  of  standards  that  are  required.  It  is  critical  to 
perform  a  realistic  analysis  of  the  neecte  of  your  organization  before  investing 
in  any  CASE  tool.  A  common  mistake  of  managers  Is  to  misunderstand 
where  the  major  effort  is  spent  during  software  development  in  their 
organization.  A  rule  of  thumb  for  long-lived  DoD  applications  is  that 
significantly  more  money  will  be  spent  on  maintenance  efforts  than  on 
original  development.  Therefore,  foe  most  cost-effective  tool  over  the  tong 
run  is  likely  to  be  foe  one  that  improves  foe  maintenance  process  to  the 
greatest  degree.  Another  rule  of  thumb  for  foe  development  portion  of  the  life 
cycle  for  DoD  applications  is  that  foe  greatest  single  cost  during  development 
is  for  documentation  efforts  [Jones,  1990].  Therefore,  a  tool  that  simplifies 
documentation  may  be  appropriate  for  many  organizations. 

•  Project  Size  and  Domain.  Both  of  these  factors  can  influence  greatly  foe 
selection  and  use  of  tools.  For  example,  a  large  project  will  need  to  pay 
careful  attention  to  such  issues  as  coc^rative  processing,  database  size, 
and  project  management.  A  hard  real-time  project  will  be  concerned  with 
issues  such  as  simulation  and  scheduling,  while  an  MIS  project  will  require 
strong  database  capabilities. 

•  Organizational  Expectations.  The  appropriate  tool  will  depend  on  what 
your  organization  expects  from  it.  if  you  expect  immediate  productivity  or 
quality  improvement  on  the  next  piece  of  software  develops,  then  it  may  be 
inadvisable  to  purchase  an  analysis  and  design  tool  requiring  significant 
training  and  a  long  term  commitment  on  a  methodology.  On  the  other  hand, 
if  such  a  purchase  is  part  of  a  carefully  thought  out  plan  for  long-term 
improvement  in  methods  and  process,  then  foe  tool  may  be  a  worthwhile 
investment.  Note  that  other  ty^s  of  CASE  tools  may  require  less  training, 
and  have  a  shorter  period  for  ROI.  These  tools  may  address  immediate 
needs  more  effectively. 

3.2  Will  new  tools  help  me  Improve  my  software  process? 

Increased  competition  and,  in  some  cases,  SEI  assessments  are  causing  many  organizations 
to  reconsider  how  effectively  they  develop  software.  It  is  natural  for  them  to  look  to  additional 
tool  support  as  one  method  of  Improving  their  software  process.  In  fact,  the  SEI  capability  ma¬ 
turity  model  lists  the  provision  of  appropriate  resources  (including  tool  support)  as  a  key  pro¬ 
cess  area  in  maturity  levels  2-5,  and  in  a  number  of  places  provides  examples  of  tools. 

A  key,  but  often  overlooked  point,  however.  Is  that  the  tools  used  by  a  software  organization 
must  reflect  the  software  methods  and  practices  in  place  within  the  organization.  [Smith  & 
Oman,  1 990]  advise  that  an  overall  tool  strategy  for  an  organization  or  project  should  consider 
the  process  and  methods  in  place,  determine  the  functions  of  the  life  cycle  that  need  to  be  sup¬ 
ported,  and  account  for  the  environmental  infrastructure  that  will  let  tools  work  together. 

For  a  tool  to  be  successful  in  a  large-scale  development  project,  it  must  support  a  process  that 
is  well  entrenched  rather  than  existing  outside  foe  bounds  of  the  process.  Those  tools  that  of¬ 
fer  a  useful  service,  but  do  not  fit  smoothly  into  foe  existing  process,  are  not  likely  to  be  suc- 
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cessfully  used  on  large  projects.  Likewise,  tools  can  present  additional  problems  due  to  the 
data  transfer  incompatibilities  between  other  tools  in  different  deveiopment  stages  requiring 
that  data  be  reentered  manuaiiy. 

Organizations  at  different  ievels  of  process  maturity  are  iikely  to  have  different  needs  for  toois 
and  to  use  toois  differently.  A  reasonable  first  step  is  to  analyze  the  process  maturity  level, 
develop  a  plan  for  improvement,  and  incorporate  the  tool  strategy  into  the  improvement  plan. 

3.3  How  does  the  life-cycle  model  affect  my  tools? 

What  model  of  software  development  an  organization  accepts  will  influence  its  practices.  Dur¬ 
ing  the  1 970s  and  much  of  the  1 980s,  the  waterfall  model  was  the  accepted  model  for  the  soft¬ 
ware  development  process.  The  software  maintenance  process  was  often  viewed  as  a  smaller 
scale  analog  of  the  development  process.  It  is  not  surprising,  then,  to  find  the  major  features 
of  the  waterfail  model  embedded  in  government  standards  such  as  DOD-STD-2167A.  in  the 
methodologies  supported  by  commonly  available  tools,  and  in  software  environments  based 
on  these  standards  and  tools. 

Recently,  additional  software  development  models  have  been  suggested.  These  Include  the 
spiral  model  [Boehm.  1988]  and  various  models  based  on  rapid  prototyping  and  reuse  of  ex¬ 
isting  software  components.  It  is  unclear  whether  any  of  these  new  models  will  supersede  the 
waterfall  model  as  the  accepted  standard.  In  fact,  it  is  most  likely  that  the  software  community 
is  entering  a  period  where  multiple  models  of  the  software  development  cycle  are  common. 

Different  development  models  can  place  a  premium  on  different  tools.  For  example,  a  rapid 
prototyping  model  of  development  may  require  tools  to  rapidly  generate  user  interfaces.  Other 
influences  of  the  development  model  on  software  tool  support  may  be  less  obvious.  For  ex¬ 
ample,  the  use  of  a  cyclic  model  may  require  rapid  and  frequent  transitions  between  life-cycle 
phases,  and  therefore  require  a  tightly  Integrated  tool  set  to  minimize  life-cycle  disruption.  On 
the  other  hand,  a  traditional  waterfall  model  may  be  adequately  supported  by  a  less  tightly  in¬ 
tegrated  tool  set.  or  even  by  manual  conversion  of  data  from  phase  to  phase. 

3.4  Which  methodology  should  I  choose? 

Current  CASE  analysis  and  design  tools  primarily  support  structured  methods  like  those  pro¬ 
posed  by  Yourdon.  In  addition  to  these  well-accepted  methods,  new  object-oriented,  rapid 
prototyping,  and  reuse-oriented  methodologies  are  being  introduced.  There  is  debate  in  the 
software  engineering  community  concerning  the  effectiveness  of  the  various  methods,  partic- 
uiariy  for  large  systems.  Proponents  of  object-oriented  methodologies  believe  that  these  new¬ 
er  methods  offer  better  overall  system  design,  faciiitating  reuse  of  software  components. 
Proponents  of  rapid  prototyping  methodologies  argue  that  they  are  best  able  to  establish  user 
requirements  and  reduce  the  risk  of  development.  Proponents  of  established  structured  meth¬ 
ods  point  to  a  variety  of  successful  systems  developed  with  their  preferred  methodology. 
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Interestingly,  there  is  little  or  no  empirical  data  to  suggest  that  one  specific  method  will  lead  to 
greater  success.  [Wood  &  Wood.  1990]  found  little  to  support  the  choice  of  one  structured 
method  over  others,  in  addition,  it  is  unclear  whether  the  use  of  newer  object-oriented,  proto¬ 
typing-oriented.  or  reuse-oriented  methods  will  enhance  the  chances  for  success.  Successful 
and  unsuccessful  projects  have  been  attempted  with  all  of  the  contending  methodologies. 

A  reasonable  start  to  identifying  an  appropriate  tool  is  to  first  analyze  your  current  method.  If 
you  are  satisfied  with  your  current  method,  there  is  little  reason  to  change.  If  you  are  unsatis¬ 
fied  with  your  current  method,  you  may  be  best  served  by  investigating  which  methods  have 
proven  successful  for  your  particular  type  of  software.  Once  you  have  identified  an  appropriate 
method  based  on  the  experience  of  others,  you  should  first  introduce  the  method  to  your  or¬ 
ganization  prior  to  making  an  actual  tool  purchase. 

3.5  Why  do  I  need  a  CASE  strategy? 

A  tool  strategy  is  needed  to  determine  the  relationship  of  a  set  of  tools  to  the  processes  and 
methods  of  your  organization,  and  develop  an  overall  plan  for  the  adoption  of  the  tools.  The 
strategy  outlines  the  improvements  required  in  the  current  software  development  process  and 
how  these  improvements  will  be  made. 

In  accordance  with  the  “Awareness  and  Commitment”  stage  of  the  CASE  adoption  process 
(outlined  in  Section  2).  a  CASE  strategy  has  a  number  of  basic  (or  “front-end”)  parts,  including; 

•  analysis  of  software  engineering  process 

•  analysis  of  methods  for  software  development 

•  analysis  of  model  for  software  development 

•  development  of  overall  improvement  plan 

•  analysis  of  current  environment  and  tools 

•  development  of  tool  strategy 

Implementing  tools  may  be  only  one  part  of  a  strategy.  For  example,  a  strategy  centered 
around  improving  the  data  management  of  an  organization  may  not  need  to  incorporate  tools 
since  the  bulk  of  the  work  is  primarily  manual.  A  CASE  tool  could  certainly  help  enforce  the 
data  standards,  but  implementing  a  CASE  tool  solely  for  this  purpose  would  probably  not  be 
cost  effective. 

Details  of  the  development  of  an  improvement  strategy  are  beyond  the  scope  of  this  guide,  but 
can  be  found  in  [Fowler  &  Rifkin,  1990]. 

3.6  How  do  new  tools  fit  within  my  current  environment? 

Some  CASE  tool  vendors  advertise  the  openness  of  their  tool  offering  and  imply  that  the  tool 
can  be  easily  integrated  into  an  existing  development  environment.  Many  vendors  are  in  fact 
working  hard  to  improve  the  external  accessibility  of  tool  data.  Even  if  our  most  optimistic  ex- 
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pectations  for  open  architectures  were  exceeded,  however,  it  is  uniikely  that  tools  would  fit  into 
an  existing  environment  in  a  "plug  compatible”  manner. 

Often,  because  of  its  characteristics,  a  new  tool  can  be  difficult  to  fit  into  an  organization's  ex¬ 
iting  environment.  Even  those  tools  that  are  relatively  open  tend  to  perfonn  their  functions  in 
an  egotistic  manner,  as  if  they  are  the  center  of  the  tool  “universe."  In  general,  tools  tend  to 
provide  unique  functionality  rather  than  relying  on  services  provided  by  existing  environment 
functions.  For  example,  many  CASE  tools  provide  a  configuration  management  (CM)  function 
that  does  not  utilize,  and  in  some  cases  conflicts  with  the  functions  provided  by  CM  systems. 
Similarly,  instead  of  using  existing  commerdal  data  management  systems,  most  CASE  tools 
provide  a  customized  system. 

This  "home  grown”  approach  to  tool  functionality  was  adopted  by  CASE  vendors  for  three  pri¬ 
mary  reasons:  it  provided  complete  control  over  the  technology  offered  by  the  tool,  it  allowed 
tuning  of  the  system  for  best  performance,  and  it  allowed  vendors  to  provide  a  turn  key  system 
with  few  dependencies  on  other  environment  software.  Unintentionally,  the  end  result  has 
been  to  make  tools  more  difficult  to  integrate  into  user  environments. 

Perhaps  a  larger  part  of  the  difficulty  of  integrating  a  new  tool  into  an  existing  environment,  and 
as  well  as  a  reason  why  tools  may  never  be  completely  “plug  compatible.”  is  the  relationships 
between  tools  and  the  existing  process,  methods,  and  personnel.  It  is  possible  (in  fact  likely) 
that  some  reworking  of  the  process  and  methods,  as  well  as  retraining  of  staff  will  be  neces¬ 
sary.  It  has  been  suggested  that  the  more  tightly  integrated  the  tools  of  the  existing  environ¬ 
ment,  the  more  work  will  be  necessary  to  replace  a  tool.  It  is  also  likely  that  the  more  highly 
defined  your  process,  the  more  tool  adaptation  that  will  be  necessary.  Even  where  tools  pro¬ 
vide  integrated  capabilities  to  perfonn  a  major  step  in  an  organization’s  development  process 
(such  as  the  generation  of  DOO-STD-2167A  documentation),  experience  suggests  that  great 
effort  must  be  expended  to  make  the  product  usable  due  to  limitations  of  the  integration,  as 
well  as  variance  in  the  requirements  of  the  organization. 

A  useful  step  in  ameliorating  the  problems  of  integrating  a  new  tool  into  an  existing  environ¬ 
ment  is  to  develop  a  specific  action  plan  which  addresses  integration  with  other  tools,  process¬ 
es.  methods,  and  people  as  part  of  a  tool  strategy.  The  action  plan  should  address  the  building 
of  bridges  between  the  new  tool  and  the  existing  components  of  the  environment  (tools,  pro¬ 
cesses,  methods,  and  people). 

3.7  What  are  the  long-term  implications  of  a  tool  decision? 

It  has  been  argued  in  the  CASE  literature  that  the  primary  benefits  of  CASE  tools  come  not 
from  the  savings  during  initial  development,  but  rather  from  savings  that  become  apparent  dur¬ 
ing  maintenance  [Andrews.  1 989].  Thus,  it  can  be  expected  that  a  tool  that  offers  a  large  return 
on  investment  will  be  one  that  lives  a  long  life.  The  consequences  for  the  long  life  expectancy 
and  cost  of  a  CASE  tool  can  be  profound.  Consider  the  following  scenarios: 
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•  You  are  buying  more  than  a  tool.  You  are  also  buying  the  future  of  a 
company.  Because  of  the  significant  costs  for  the  tool,  plus  the  tremendous 
effort  invested  in  making  it  work  for  the  organization,  you  will  be  unlikely  to 
convince  management  to  switch  to  another  tool.  You  can  expect  your  original 
commitment,  if  it  becomes  institutionalized,  to  be  maintained  over  a  number 
of  years. 

•  Your  tooi  choice  wili  exert  profound  influence  over  subsequent  tool  and 
environment  decisions.  Subsequent  choices  wili  be  practically  limited  to 
those  vendors  what  maintain  strong  relationships  with  your  CASE  tool 
vendor. 

•  Your  staffing  needs  for  training  and  system  support  wili  increase  significantiy. 

Among  the  most  expensive  aspects  of  tool  adoption  is  the  development  and 
retention  of  in-house  tool  experts  who  can  cope  with  the  many  tool  support 
problems  expected.  Some  organizations  using  sophisticated  CASE  tools 
have  found  that  the  level  of  expertise  and  support  necessary  is  closer  to  that 
required  for  an  operating  system  than  to  that  required  for  a  word  processing 
program. 

•  You  will  need  to  cultivate  continued  support  from  high  level  management. 

Many  organizations  have  chosen  a  CASE  tooi.  used  it  with  moderate 
success  on  a  few  projects,  and  then  abandoned  the  tool  due  to  a  lack  of  long¬ 
term  commitment  to  make  it  work  in  the  organization’s  environment. 

Successful  implementors  of  CASE  toots  often  have  strong  advocates  at  high 
levels  of  management  who,  when  faced  with  a  project  manager  experiencing 
tool-related  delays,  provide  appropriate  support  for  the  project  and  honestly 
address  the  delays,  but  also  demand  that  the  tool  be  made  to  work. 

•  You  must  gain  control  over  tool  and  environment  configurations  such  that  you 
can  rapidly  reconfigure  the  tool  environment  of  a  software  component.  This 
is  made  difficult  by  the  numbers  and  frequency  of  tool  releases,  and  the 
developing  interdependence  among  various  versions  of  tools. 

•  You  should  track  emerging  tooi  and  environment  technology,  and  emerging 
standards,  and  relay  your  thoughts  and  concerns  to  the  vendor  in  the  hope 
of  influencing  future  tool  directions.  One  of  the  best  ways  to  do  this  is  through 
participation  in  an  active  and  vocai  user’s  group. 

A  software  organization  that  wishes  to  use  sophisticated  tools  must  obviously  develop  a  strat¬ 
egy  to  manage  the  change  in  tools  over  the  life  cycle  of  the  affected  software  products.  Such 
change  is  common  and  hardly  ever  comfortable,  but  far  less  painful  if  planned. 


3.8  How  are  tools  integrated? 

While  this  report  is  not  intended  as  a  guidebook  for  organizations  that  wish  to  integrate  tools, 
a  background  in  the  types  and  techniques  of  tool  integration  may  be  useful  for  those  purchas¬ 
ing  tools  as  well.  An  analysis  of  the  various  levels  of  integration  can  be  found  in  [Brown  &  Mc- 
Dermid,  1991],  while  a  more  complete  explanation  of  the  types  of  integration  is  available  in 
[Thomas  &  Nejmeh,  1992]. 
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[Wasserman,  1990]  identified  five  types  of  integration: 

1.  Platform  Integration 

2.  Presentation  Integration 

3.  Control  Integration 

4.  Data  Integration 

5.  Process  Integration 

3.8.1  Platform  Integration 

Platform  integration  refers  to  incorporation  of  a  tool  with  a  common  set  of  services  provided 
by  the  computing  environment.  For  example,  the  UNIX  environment  provides  a  form  of  plat¬ 
form  integration  for  tools.  In  some  respects,  this  is  the  least  interesting  form  of  integration  be¬ 
cause  it  does  not  deal  directly  with  tool-to-tool  integration. 

3.8.2  Presentation  Integration 

Presentation  integration  refers  to  the  provision  of  a  consistent  user  interface  across  tools. 
Such  consistency  can  greatly  simplify  the  use  of  a  tool  set.  In  addition,  the  time  and  cost  of 
comprehensive  training  and  support  is  reduced.  Standardized  user  interfaces  can  ultimately 
lead  to  greater  tool  choice  and  flexibility  for  users. 

Organizations  have  long  tried  to  achieve  a  form  of  presentation  integration  by  developing  user 
interface  standards  for  internal  tools  and  by  providing  graphics  user  interface  "wrappers” 
around  (primarily  command  line  based)  external  tools. 

More  recently  the  X  Window  System,  in  conjunction  with  the  Motif  look-and-feel  format,  has 
achieved  broad  support.  It  is  important  to  recognize,  however,  that  the  X  Window  System/Motif 
combination  does  not  provide  complete  presentation  integration.  Vendors  remain  free  to  use 
unique  vocabulary  and  menu  contents. 

3.8.3  Control  Integration 

Control  integration  refers  to  the  ability  of  tools  to  inform  other  tools  of  their  actions  and  to  re¬ 
quest  actions  by  other  tools.  A  very  rudimentary  form  of  control  integration  is  represented  by 
command  line  invocation  of  one  tool  by  another.  Unfortunately,  command  line  invocation  is  in¬ 
adequate  to  provide  the  level  of  integration  required  by  users.  Users  (justifiably)  demand  that 
integration  occur  at  the  level  of  the  actions  which  occur  in  individual  tools.  Thus,  at  the  moment 
of  a  design  action  within  a  CASE  analysis  and  design  tool,  notice  or  access  to  other  tools  af¬ 
fected  by  the  change  would  ideally  be  immediate. 

Organizations  have  long  achieved  a  rudimentary  form  of  control  integration  by  using  mecha¬ 
nisms  such  as  UNIX  shell  scripts  to  invoke  tools  in  order  to  achieve  an  ordering  of  tool  func¬ 
tioning.  An  increasing  number  of  tools  are  incorporating  more  sophisticated  mechanisms  such 
as  programmatic  interfaces  that  provide  access  for  finer-grained  control  over  tools.  Unfortu- 
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nately,  the  use  of  these  interfaces  often  leads  to  point-to  point-integrations  of  individual  tools, 
since  there  is  no  universal  standard  for  the  form  and  function  of  programmatic  interfaces.  Such 
point-to-point  integrations  are  expensive  tx)th  to  create  and  maintain,  and  effectively  limit  the 
user’s  flexibility  when  replacing  a  tool,  since  competing  tools  are  likely  to  provide  different  in¬ 
terfaces. 

A  more  complex  but  promising  mechanism  includes  a  monitor  that  receives  tool  notifications 
or  requests  and  subsequently  sends  appropriate  notifications  and  requests  to  other  tools  in 
the  environment.  Hewlett-Packard's  SoftBench  is  currently  the  most  prominent  example  of  this 
technology,  although  other  vendors  such  as  Digital  Equipment  are  preparing  to  offer  similar 
products.The  technique  requires  that  the  monitor  maintain  an  overview  of  both  the  other  tools 
in  the  environment  and  the  process  that  is  to  be  implemented,  but  it  offers  the  advantage  of 
centralizing  control  Integration  processing.  Unfortunately,  tool  vendors  have  yet  to  agree  on 
the  events  involved  in  the  sending  or  receiving  of  a  message,  however  there  is  industry  inter¬ 
est  in  generating  such  standards. 

3.8.4  Data  Integration 

Data  integration  refers  to  the  transfer  of  information  between  tools,  and  the  establishment  of 
relationships  between  data  utilized  by  different  tools.  One  common  method  of  data  integration 
requires  that  individual  tools  agree  on  specific  interchange  formats  or  interfaces.  This  ap¬ 
proach  is  relatively  simple  to  implement  and  widely  applicable  to  many  types  of  tools.  Perhaps 
the  most  common  of  such  interchange  formats  is  represented  by  ASCII  files.  More  elaborate 
interchange  standards,  such  as  COIF  (CASE  Data  Interchange  Format)  [Chappell,  Downes, 
&  Tully,  1989],  are  also  supported  by  a  number  of  tool  vendors.  Such  methods,  however,  pro¬ 
vide  only  for  the  exchange  of  data  and  are  not  effective  at  establishing  links  between  data 
maintained  by  different  tools,  or  at  maintaining  the  semantic  context  of  data. 

A  second  approach  to  data  integration  has  been  the  development  of  filters  which  extract  por¬ 
tions  of  data  from  individual  tools  and  store  this  data  into  a  secondary  database  for  processing 
by  other  tools.  This  approach  has  been  commonly  used  to  extract  data  from  tools,  organize 
the  data  along  some  schema,  store  it  in  a  central  database,  and  then  use  the  data  to  generate 
reports  and  documents.  This  approach  allows  the  generation  of  arbitrary  relationships  be¬ 
tween  tool  data  but,  like  the  previous  approach,  results  in  the  maintenance  of  point-to-point 
integrations  (between  filters  and  tools),  as  well  as  duplication  of  data  in  the  individual  tools  and 
central  database. 

A  third  method  for  achieving  data  integration  involves  the  development  of  a  shared  repository 
in  which  a  variety  of  toots  store  information.  A  fully  functioning  repository  would  provide  the 
capability  of  maintaining  a  core  semantic  content  of  objects  together  with  tool-specific  views, 
and  because  of  the  common  dictionary  would  permit  several  tools  to  work  together.  Reposito¬ 
ries  (such  as  PCTE  1.5,  and  later  ECMA  PCTE)  [Thomas,  1989]  are  becoming  available,  and 
have  been  discussed  widely  but,  in  our  opinion,  are  still  several  years  from  maturity. 
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3.8.5  Process  Integration 

Process  integration  refers  to  the  automation  of  the  sequence  of  activities  in  support  of  an  or¬ 
ganization’s  defined  process  for  the  software  life  cycie.  To  achieve  a  high  level  of  process  in¬ 
tegration,  the  mechanisms  of  presentation,  control,  and  data  integration  are  used.  In  effect, 
process  integration  is  the  end  toward  which  the  other  forms  of  integration  provide  a  means. 

While  process  integration  has  been  the  overall  goal  of  many  integration  attempts,  little  is 
known  about  the  characteristics  and  parameters  of  quality  process  integration.  Ideally,  a  well 
integrated  process  would  support  an  organization's  activities  without  mandating  a  single  rou¬ 
tine.  The  well  integrated  process  would  insure  that  milestones  and  standards  are  met,  but  pro¬ 
vide  for  flexibility  in  the  meeting  of  those  standards  and  milestones. 

Commercial  organizations  involved  in  the  development  of  integrated  environments  must  ad¬ 
dress  this  simultaneous  need  for  structure  and  flexibility.  They  must  develop  an  environment 
which  provides  an  adequate  degree  of  process  Integration,  while  at  the  same  time  allowing 
adequate  flexibility  to  support  a  wide  customer  base.  Fortunately,  after  initially  devoting  most 
of  their  time  to  the  technical  aspects  of  the  solution,  many  environment  builders  now  recognize 
the  difficulty  in  defining  and  supporting  a  set  of  domain  specific  processes,  and  are  pursuing 
solutions  that  provide  balanced  presentation,  control,  and  data  integration. 


3.9  Can  I  integrate  tools  myself? 

While  it  is  possible  to  perform  limited  integrations  of  CASE  tools  yourself,  many  of  the  largest 
corporate-directed  integration  efforts  have  proven  to  be  technically  risky  and/or  too  costly,  and 
were  later  scaled  down  or  abandoned.  A  number  of  problems  are  evident  with  corporate-di¬ 
rected  integrations,  among  them; 

•  The  level  of  integration  that  can  be  achieved  without  modification  of  individual 
tools  is  limited.  While  many  vendors  claim  to  offer  "open”  access  to  their  tool, 
this  is  often  limited  to  data  access  routines.  Unfortunately,  semantic 
information  is  often  embedded  in  the  tool  functioning,  and  is  therefore 
unavailable  for  integration. 

•  Tool  vendors  are  not  likely  to  perform  significant  modifications  in  support  of 
a  single  customer  because  of  the  configuration  problems  that  it  causes  for 
them.  Without  such  modifications,  the  degree  of  integration  possible  will  be 
severely  limited. 

•  The  initial  cost  of  performing  complex  modifications  to  CASE  tools  is 
prohibitive,  even  if  access  is  provided  to  source  code.  CASE  tools  are  large 
systems,  with  many  sized  In  the  range  of  hundreds  of  thousands  of  lines  of 
code.  They  are  simply  too  large  and  complex  to  be  modified  by  users. 

•  The  real  costs  of  CASE  tool  adoption  must  include  significant  funding  for  the 
transition  process.  If  integration  efforts  effectively  reduce  the  portion  of  the 
total  CASE  budget  available  for  transition,  then  the  CASE  adoption  effort  is 
likely  to  fail.  Some  organizations  that  have  attempted  to  provide  their  own 
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large-scale  integrations  of  CASE  tools  have  found  that  roughly  half  of  the 
expense  of  the  CASE  initiative  should  be  devoted  to  the  transition  effort 
involving  awareness  education,  staff  Gaining,  and  proposal  arxl  operation 
support. 

•  The  problems  associated  with  maintaining  a  user-integrated  CASE  solution 
are  significant.  CASE  tools  change  rapidly  as  new  capabilities  are  added  and 
new  platforms  are  supported.  As  a  result,  users  can  expect  frequent  releases 
of  tools.  Obviously,  if  two  or  more  CASE  tools  are  involved  in  an  integration, 
a  new  version  of  some  tool  involved  in  the  integration  can  be  expected  even 
more  frequently.  The  maintenance  problem  is  compounded  by  the  expected 
life  span  of  the  integrated  tools.  To  maximize  an  organization's  return  on 
investment,  the  tool  suite  used  to  develop  application  software  should  be 
available  throughout  the  life  cycle  of  that  software.  Thus,  customer  provided 
tool  suite  integrations  may  have  to  be  supported  for  decades. 

•  It  is  unlikely  that  customer  integrations  will  be  compatible  with  the  framework 
support  provided  by  commercial  offerings,  such  as  AD  Cycle,  AIX  CASE, 

Cohesion,  PCTE,  and  SoftBench.  Such  commercial  framework  offerings 
provide  the  best  chance  for  integrated  solutiotis. 

In  summary,  simple  integrations  that  require  no  changes  to  CASE  tools,  and  that  can  be  easily 
discarded  for  new  technologies  offered  in  the  commercial  sector,  are  probably  realistic.  Such 
integrations,  which  are  often  accomplished  via  scripts,  have  proven  useful. 


3.10  Can  tools  handle  large  applications? 

Tools  have  made  significant  gains  in  their  abilities  to  handle  moderately  sized  applications. 
They  now  can  operate  on  large  numbers  of  data  items,  and  In  many  cases  perform  adequate¬ 
ly.  This  improvement  is  due  both  to  the  increasing  sophistication  of  the  tools,  and  to  the  en¬ 
hanced  performance  of  the  computing  platform  on  which  they  operate. 

However.  CASE  tools  continue  to  suffer  performance  degradation  and  inadequate  capacity 
when  used  for  the  development  and  support  of  very  targe  applications.  Operations  on  a  very 
large  database  or  data  dictionary  can  become  prohibitively  expensive  due  to  the  significant  re¬ 
sources  and  time  required. 

In  private  discussions  with  the  SEI,  one  builder  of  very  large  systems  (hundreds  of  thousands, 
and  millions  of  lines  of  code)  indicated  that  no  tool  has  yet  been  found  for  which  some  capacity 
limitation  was  not  exceeded  during  system  development.  High  quality  tools  tend  to  degrade 
gracefully  and  provide  a  work  around  at  the  system  limits  (often  by  allowing  configuring  of  the 
system  into  multiple,  smaller  subsystems),  while  lesser  quality  tools  degrade  rapidly  and  fail 
catastrophically  by  losing  data. 

Users  of  CASE  tools  for  very  large  systems  have  found  the  responsiveness  of  the  tool  vendor 
in  problem  situations  to  be  critical  to  tool  success.  These  users  often  express  the  sentiment 
that  you  can  assume  some  problems  with  any  tool  for  the  largest  systems,  but  a  good  working 
relationship  with  the  vendor  can  lessen  the  impact  of  many  problems. 
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3.11  How  do  I  determine  the  “openness”  of  a  tool? 

Almost  all  vendors  claim  that  their  tools  are  “open”  or  “easy  to  integrate.”  yet  it  is  obvious  that 
these  claims  mean  different  things  to  different  vendors.  In  spite  of  the  difficulty  in  determining 
“openness,”  we  can  make  a  number  of  statements  about  an  idealized  open  tool: 

•  The  tool  would  adhere  to  the  commonly  accepted  “open"  standards,  including 
UNIX  (POSIX  compliance),  the  X  Window  System  for  workstations,  and  the 
Motif  look-and-feei. 

•  All  features  available  at  any  level  of  the  tool's  user  interface  would  be 
available  via  programmatic  interfaces  to  all  outside  tools. 

•  The  tool  would  be  composed  of  separate  and  replaceable  senrices.  For 
example,  configuration  management  capabilities  would  be  provided  by 
commercially  available  configuration  management  tools,  rather  than  by  the 
specific  CASE  tool.  In  addition,  the  configuration  management  tool  would  be 
easily  replaceable  by  another,  equivalent  tool. 

•  The  tool  would  provide  a  programmable  user  interface  so  that  invocations  of 
other  external  tools  would  be  clean  and  consistent 

•  The  tool  would  be  capable  of  notifying  ottier  tools  about  its  actions  as  well  as 
receiving  information  from  other  tools  about  their  actions.  In  short,  it  must 
both  “talk"  and  “listen." 

•  The  tool  would  be  capable  of  operating  without  being  the  focus  of  the  user's 
attention. 

•  The  tool  would  adhere  to  any  commonly  accepted  data  model. 

•  The  tool  would  be  available  on  a  variety  of  common  hardware  platforms. 

In  reality,  no  available  tool  meets  this  set  of  criteria  for  openness.  In  fact,  as  tools  continue  to 
accumulate  more  services,  they  often  become  less  open  according  to  these  criteria.  We  do. 
however,  believe  that  tools  tending  toward  the  indicated  architecture  will  be  easier  to  integrate 
with  other  tools  and  more  readily  assimilated  into  developing  integration  frameworks.  To  de¬ 
termine  whether  a  tool  meets  your  current  and  long-term  requirements  for  integration,  a  num¬ 
ber  of  questions  should  be  addressed  concerning  both  your  integration  needs  and  the 
integration  capabilities  of  the  tools.  Among  the  major  questions  an  organization  should  ad¬ 
dress  concerning  the  “openness”  of  a  tool  and  potential  for  integration  into  the  environment 
include: 

•  Is  an  integrating  framework  or  backplane  being  used  or  planned  for  the  future 
by  your  organization?  By  the  tool  vendor? 

•  What  are  the  current  capabilities  of  the  tool  in  question  with  regard  to 
integration  frameworks? 

•  What  use  will  the  tool  make  of  the  integration  framework?  What  changes  will 
this  entail  for  the  tool?  Is  the  level  of  granularity  of  the  tool  integration 
appropriate  for  your  needs? 

•  What  current  and  future  standards  are  part  of  your  strategy?  How  well  does 
the  tool  meet  your  emerging  standards? 
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•  What  interfaces  would  ideally  be  available  to  allow  you  to  integrate  the  tool 
into  your  environment?  What  tool  interfaces  are  available? 

•  What  is  the  quality  of  the  documentation  describing  the  interfaces  to  the  tool? 

•  What  tool  data  is  actually  accessible  outside  the  tool?  How  is  it  accessible? 

•  What  contextual  information  is  necessary  for  full  interpretation  of  tool  data? 

•  Is  this  contextual  information  available  outside  the  tool?  How? 

•  How  much  data  is  unique  to  the  dictionary  of  the  individual  tool? 

•  is  there  incompatibility  between  the  dictionaries  of  the  current  tool  and  new 
tools? 

•  What  is  the  granularity  of  the  data  that  is  shared? 

•  Can  the  tool  invoke  other  tools?  How? 

•  At  what  points  in  processing  can  the  tool  be  invoked? 

•  Can  the  tool  operate  as  a  “slave*  to  another  tool? 

•  Can  the  tool  create  predefined  links  to  other  tools?  How  well  do  these  links 
fit  your  intended  use? 

•  Can  the  tool  create  arbitrary  links  to  otiier  tools? 

•  Does  the  tool  utilize  a  proprietary  database.  CM  system,  and/or  user 
interface  system,  or  can  the  tool  be  mated  to  a  variety  of  mechanisms? 

•  Is  the  tool  constructed  as  a  monolithic  entity,  or  as  a  set  of  semi-independent 
subsystems? 

•  What  kind  of  process  integration  is  available,  either  directly  between  the  tool 
and  other  tools,  or  indirectly  through  a  framework? 

3.12  Must  all  tools  be  "open”? 

Unless  a  tool  is  to  be  used  in  total  isolation,  and  the  work  products  of  that  tool  are  unrelated 
to  other  activities  in  the  software  process,  then  the  tool  should  be  “open”.  Of  course,  there  are 
varying  degrees  of  openness  necessary  for  different  tools  to  function  effectively  with  other 
tools.  For  example,  we  might  expect  that  an  analysis  and  design  tool  would  need  a  greater 
degree  of  openness  than  an  electronic  mall  tool.  By  this,  we  imply  that  the  analysis  and  design 
tool  should  provide  us  access  at  the  semantic  level;  while  with  the  mailer,  we  may  only  require 
the  ability  to  invoke  the  mailer,  receive  mail,  and  decode  the  (ASCII  text)  form  of  the  message. 
Simply  put.  we  wish  to  know  how  and  why  the  ^alysis  and  design  tool  performs  an  action,  but 
we  only  need  to  know  how  the  mailer  performs  an  action  (how  it  can  be  invoked). 

[Brown  &  McDermid,  1991]  define  various  levels  of  tool  integration,  including: 

•  The  carrier  level,  which  is  represented  by  the  sharing  of  byte  streams  or  data 
file  formats.  Each  tool  is  responsible  for  analysis  of  the  shared  information. 

Carrier  level  integration  is  demonstrated  by  shared  file  formats  and  byte 
streams  of  the  UNIX  operating  system,  and  is  commonly  what  we  ex^ct  of 
mailers. 
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•  The  lexical  level,  which  is  identified  by  the  sharing  of  data  structure  formats, 
often  among  a  closely  related  family  of  tools.  Documentation  tools  which 
share  a  common  data  format  and  operating  conventions  (such  as  the  use  of 

at  the  beginning  of  a  line)  use  this  approach  to  int^ration.  Unfortunately, 
the  conventions  for  understanding  the  structure  continue  to  be  embedded  in 
the  individual  tool,  and  each  input  has  to  be  analyzed  for  conformance  to  the 
convention. 

•  The  syntactic  level,  in  which  the  rules  governing  the  fomnation  of  data 
structures  are  agreed  on  within  the  tool  set.  This  level  of  integration  is 
represented  within  CASE  tool  sets  that  share  a  common  data  structure. 

•  The  semantic  level,  in  which  a  common  perception  of  data  structure  is 
combined  with  a  common  perception  of  the  underlying  semantics.  Object* 
oriented  and  entity  relationship  databases  are  directly  aimed  at  this  level  of 
integration. 

•  The  method  level  of  integration,  in  which  agreement  is  reached  not  only  on 
semantic  issues,  but  also  on  the  development  process  supported,  and  on  the 
tools  which  support  each  part  of  the  process.  This  level  of  integration  is 
necessary  to  avoid  overlaps  and  inconsistencies  between  tools. 

Brown  and  McDermid  further  point  out  that  the  tighter,  more  complete  the  level  of  integration 
used  in  a  tool  set  the  more  difficult  it  is  to  reuse  individual  tools  across  applications  or  envi¬ 
ronments.  As  a  result,  we  must  make  pragmatic  decisions  concerning  the  level  of  integration 
that  is  appropriate  (and  therefore,  the  level  of  openness  necessary)  for  tools.  It  is  suggested 
that  within  a  life  cycle  phase,  tighter  forms  of  integration  are  appropriate  (such  as  the  semantic 
and  method  levels  of  integration  of  compilers  and  debuggers  allowing  them  to  operate  on  com¬ 
mon  data  structures).  Between  life  cycle  phases,  looser  integration,  perhaps  at  the  semantic 
level,  may  be  acceptable. 

3.13  Will  vendors  customize  a  tool  for  me? 

Conversations  with  vendors  indicate  that  they  frequently  have  hundreds  of  different  customers 
requesting  unique  features.  Often  the  customer  assumes  that  others  would  also  want  the  fea¬ 
ture,  and  fails  to  see  the  uniqueness  of  the  request  CASE  tool  vendors  also  are  faced  with  a 
large  backlog  of  features  to  be  implemented  that  are  not  unique.  They  must  carefully  position 
resources  to  address  the  more  universally  desirable  features.  Rnally,  each  customization  of  a 
tool  represents  another  configuration  of  the  tool  to  be  maintained.  Vendors  complain  heartily 
about  the  current  number  of  tool  configurations  necessary  to  cover  the  market,  even  without 
considering  custom  configurations. 

In  light  of  these  backlogs,  vendors  address  tool  customization  in  three  ways:  they  will  discour¬ 
age  customization  of  tools,  they  will  provide  a  service  (at  significant  cost)  to  customize  the  tool, 
or  they  will  provide  a  degree  of  customization  capability  within  the  tool.  Only  for  the  very  largest 
customers  will  a  vendor  customize  a  tool  set  at  no  cost. 

Even  if  the  vendor  will  customize  a  tool,  it  is  unclear  whether  such  customization  is  in  the  long¬ 
term  interest  of  the  customer.  There  is  little  assurance  that  the  vendor  will  continue  to  support 
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a  tool  configuration  with  a  relatively  small  customer  base.  The  support  that  is  offered  can  be 
expected  to  come  after  upgrades  to  the  mainstream  tool  configuration.  Such  customization 
may  also  limit  the  degree  to  which  the  tool  configuration  will  be  included  in  integrations  with 
other  tools. 

The  customization  features  built  into  many  toots  represent  a  viable  (if  limited)  option  for  tool 
customization.  Such  customization  features  normally  are  represented  in  the  msunstream  con¬ 
figuration  of  the  tooi,  and  are  therefore  adequately  supported.  In  addition,  features  su<^  as 
configurable  menus  can  provide  a  mechanism  for  tooi  integration. 

3.14  What  do  vendor  integration  claims  mean? 

Many  vendors  have  begun  to  form  strategic  alliances  with  other  vendors  in  order  to  ensure 
that  their  tools  can  interact.  These  integrations,  termed  ‘t^ASE  coaiitions”  [Wallnau  &  Feiler, 
1991],  offer  a  strategic  marketing  advantage  to  the  tool  vendors,  as  well  as  a  varying  degree 
of  integration  to  users. 

in  the  near  term,  CASE  coalitions  may  provide  a  practical  solution  to  integration  of  tools  into  a 
cohesive  tool  set.  However,  the  individual  tools  of  such  integrations  continue  to  operate  in  an 
"egocentric”  manner.  Each  maintains  its  own  database  and  supports  its  own  paradigms  for 
software  development.  Each  maintains  a  unique  concept  of  multi-user  support  and  configura¬ 
tion  management.  These  non-integrated  qualities  of  CASE  coalitions  will  place  a  practical  limit 
on  the  types  of  tools  that  can  be  included  into  the  tool  set,  as  well  as  the  degree  of  integration 
provided. 

A  second  set  of  problems  occurs  due  to  the  proprietary  nature  of  these  coalitions.  Vendor 
agreements  between  tools  of  CASE  coalitions  limit  the  possibility  that  other,  competing  tools 
may  become  members.  Thus,  the  choice  of  the  user  is  limited.  In  addition,  the  strength  of  a 
coalition  offering  may  be  put  at  risk  by  the  relative  weakness  of  any  single  tool  in  the  coalition. 

Finally.  CASE  coalition  integrations  are  primarily  ad  hoc,  in  that  vendors  utilize  the  primitive 
integration  interfaces  that  are  available.  As  such,  tttese  integrations  are  difficult  to  tailor.  In  ad¬ 
dition.  it  is  unclear  whether  they  can  survive  to  compete  against  other  developing  frameworks. 
Thus,  any  purchase  of  coalition  technology  should  be  viewed  as  a  short-term  solution,  and  up¬ 
grade  paths  must  be  considered. 

3.15  What  do  CASE  tools  cost? 

A  large  number  of  factors  can  influence  initial  and  continuing  costs  of  developing  and  main¬ 
taining  a  state-of-the-art  software  development  environment.  Among  these  factors  are  the 
large  number  of  tools  necessary  in  such  an  environment,  the  costs  for  the  initial  installation, 
long-term  maintenance  costs,  the  costs  of  the  supporting  hardware  and  software  environ¬ 
ments,  and  the  costs  for  additional  and  better  trained  staff.  Some  of  the  costs  are  associated 
specifically  with  those  of  a  CASE  environment.  Others  are  connected  to  the  maintenance  of  a 
sophisticated  distributed  computing  environment. 
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3.15.1  Principal  Cost  Drivers 

[Huff,  1992]  identified  a  number  of  principal  cost  drivers  for  a  CASE  adoption  budget  Some  of 
these  cost  drivers  include: 

•  the  scope  of  the  CASE  adoption  effort  including  the  number  and  type  of 
projects  for  which  the  tool  will  be  adopted. 

•  the  complexity  of  the  existing  environment  which  will  be  affected  by  the 
CASE  adoption  effort. 

•  the  size  of  the  organization  which  will  adopt  the  tool. 

•  the  history  of  the  organization  in  dealing  with  major  changes  to  the  culture. 

•  the  current  practices  in  the  organization. 

•  the  skill  level  of  targeted  end  users,  and 

•  the  speed  at  which  the  transition  is  to  occur. 

3.15.2  Start-Up  Costs 

There  is  not  substantial  empirical  data  available  on  the  cost  of  providing  such  a  full  set  of  soft¬ 
ware  development  tools.  However,  instructive  lessons  can  be  learned  from  the  projected  costs 
associated  with  the  implementation  of  a  tool  and  the  associated  support  for  a  staff  of  75  engi¬ 
neers.  Obviously,  these  costs  could  vary  substantially  depending  on  the  characteristics  and 
needs  of  the  organization. 

Figure  3-1  contains  a  list  of  the  projected  start-up  costs  from  [Huff,  1992].  Additional  cost  es¬ 
timates  are  available  from  [Grochow,  1988]. 


Initial  Investment 

1  Total 
j  Cost 

1  Per 

j  Seat 

1  Comment 

Technical  Assessments 

$138,750 

$1,850 

Process,  standards,  infrastructure,  market, 
etc. 

Organizational  Assessments 

$22,500 

$300 

Organization,  people,  economic 

CASE  Software 

$187,500 

$2,500 

Estimated  average  price  per  package 

Workstations 

$562,500 

$7,500 

Estimated  average  price  per  workstation 

Skills  Development  —  Training 

$375,000 

$5,000 

Twice  the  value  of  CASE  software 

Tool  Consultants 

$50,000 

$667 

50  days  at  $1  .OOOAday 

Total  Initial  Investment: 

$1,336,250  ; 

$17,817 

AdapMd  From:  Qioehow,  J.  M.  *Ju«ifyir)g  ttw  Coot  of  CASE  *  Oompu«on«arM<Fobn>ary  8, 1988). 


Figure  3-1  Start-Up  CASE  investment 

According  to  the  data  presented  in  Figure  3-1 .  the  total  start-up  costs  associated  with  the  in¬ 
vestment  in  a  sophisticated  tool  for  75  users  would  be  approximately  1 .3  million  dollars,  it 
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should  be  noted  that  this  estimate  includes  $562,500  allocated  toward  the  purchase  of  a  set 
of  workstations  at  $7,500  per  unit.  Such  a  purchase  may  or  may  not  be  necessary,  depending 
on  whether  appropriate  hardware  is  already  available.  In  addition,  if  high  performance  work¬ 
stations  are  necessary,  costs  may  easily  exceed  $7,500  per  unit.  It  may  be  possible  to  reduce 
this  cost  by  purchasing  a  smaller  number  of  high  performance  workstations  supported  by  X 
terminals. 

3.15.3  Ongoing  Costs 

In  addition  to  the  start-up  costs  associated  with  Uie  tool  implementation,  ongoing  costs  must 
be  considered.  An  estimate  of  these  costs  is  provided  in  Figure  3-2  [Huff,  1992].  Again,  addi¬ 
tional  estimates  are  provided  In  [Grochow.  1988]. 


1 

Ongoing  Operations 

Total 

Cost 

Per 

Seat  j 

Comment 

Software  Engineering  Support 
Group 

$150,000 

$2,000 

3  people  at  $50,000  (salary  &  benefits) 

Hardware  Maintenance 

$37,500 

$500 

Estimated  $500  per  year  for  each 
workstation 

Software 

Upgrades/Maintenance 

$28,125 

$375 

Estimated  15%  per  year  for  each 
workstation 

Ongoing  Training 

$39,375 

$525 

3-days'  annual  training  per  person  at 
$175/day 

Conferences  —  User  Group 
Meetings 

$12,000 

$160 

2  people  attending  4  meetings  at 
$1 ,500/meeting 

Miscellaneous 

$5,000 

$67 

Books,  subscriptions,  publications 

Total  Ongoing  Costs 

$272,000  1 

1 

$3,627 

Adapwd  From;  Qiochow,  J.  M.  ‘JkjstVnO  Coot  of  CASE,*  CompuifwoM(F*bnmy  8, 1988). 


Figure  3*2  Ongoing  CASE  Costs 

It  is  possible  that  the  costs  for  a  Software  Engineering  Support  Group  may  far  exerted  the  sug¬ 
gested  $150,000  for  three  support  personnel.  Experience  within  the  SEI  indicates  that  the 
maintenance  of  network  software,  particularly  for  heterogeneous  networks,  can  be  demanding 
and  requires  both  a  greater  number  and  a  more  highly  trained  (and  paid)  staff.  Some  experi¬ 
enced  users  suggest  that  the  complexity  and  management  of  a  sophisticated  CASE  analysis 
and  design  tool  is  more  akin  to  that  of  an  operating  system  than  to  that  of  a  less  sophisticated 
tool  such  as  a  simple  text  editor. 

3.16  What  determines  the  impact  of  a  tool? 

The  potential  impact  of  a  tool  on  an  organization  is  difficult  to  predict  because  many  factors 
are  invoived.  In  our  view,  CASE  impact  depends  on  an  interrelated  network  of  factors  (Figure 
3-3). 
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Although  much  has  been  published  about  CASE,  the  early  anecdotal  studies  of  the  impact  of 
CASE  tools  did  not  distinguish  among  the  effects  of  tools,  associated  changes  to  the  organi¬ 
zation's  process  and  methods,  or  the  way  in  which  tools  were  adopted.  Such  factors  can  have 
major  conflicting  or  confounding  effects  on  productivity  or  quality.  Additional  research  will  be 
needed  to  separate  these  influences. 

Figure  3-3  does  suggests  that  tool  characteristics,  while  important,  represent  only  one  of  the 
factors  that  determine  the  effectiveness  of  tools.  There  is  a  need  to  carefully  account  for  orga¬ 
nization-specific  factors,  such  as  the  size,  resources,  and  culture.  The  way  in  which  tools  are 
adopted  can  have  an  additional  long-term  impact. 


Figure  3-3  Factors  That  influence  CASE  Impact 


3.17  How  do  I  maximize  my  return  on  investment? 

Return  on  investment  (ROI)  depends  on  the  development  of  a  sound  strategy  that  makes 
sense  for  an  organization.  As  previously  indicated,  there  are  several  prerequisites  that  must 
be  satisfied.  An  organization  should  be  serious  about  its  software  engineering  process,  and 
should  be  actively  Involved  in  an  improvement  effort.  There  should  be  a  set  of  development 
methods  in  place.  Given  that  the  prerequisites  are  in  place,  there  needs  to  be  an  understand¬ 
ing  of  the  organization  and  what  works  within  an  organization,  including  issues  of  cultural 
change.  A  full  range  of  tools,  working  together  to  solve  a  software  engineering  problem,  may 
be  more  effective  than  any  individual  tool.  The  set  of  tools  must  be  integrated  within  the  con¬ 
text  of  an  overall  tool  strategy.  Standards  and  practices  must  be  instantiated  for  a  particular 
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organization,  with  specific  concern  for  the  process  and  methods  of  that  organization.  Cultural 
issues  are  then  addressed,  along  with  the  roles  and  management  checkpoints  of  the  adoption 
life  cycle. 

3.18  What  are  major  non-technical  tool  considerations? 

Perhaps  the  most  difficult  hurdle  to  overcome  is  the  idea  that  by  introducing  a  CASE  tool  in 
the  work  environment,  the  implementor  of  the  tool  is  actually  changing  the  way  that  people  do 
their  work  both  physically  and  mentally.  Change  can  often  make  people  feel  uncomfortable. 

Although  it  might  appear  that  during  the  adoption  process  the  main  concerns  are  the  technical 
issues  surrounding  the  selection  of  the  CASE  tool,  many  of  the  cultural  aspects  of  the  adopting 
organization  can  have  significant  impacts  as  well.  Issues  such  as  morale,  perceived  resistance 
to  tools,  and  roles  that  people  in  the  organization  fulfill  need  to  be  considered  as  issues  that 
affect  the  adoption  process. 

Morale  is  not  something  that  immediately  comes  to  mind  when  one  thinks  about  the  adoption 
process.  Upon  further  inspection,  it  makes  sense  that  an  organization  currently  experiencing 
a  low  point  would  be  least  likely  to  accept  new  ideas.  The  prevailing  apathy  can  grow  quickly. 
Under  these  circumstances  motivating  such  an  organization  to  accept  new  technology  can  be 
a  difficult  task. 

Perceived  resistance  is  also  a  very  real  problem  to  overcome.  Tools  can  enforce  a  methodol¬ 
ogy  that  is  perceived  as  being  restrictive.  This  is  just  one  reason  that  software  engineers  give 
for  not  using  CASE  tools.  However,  getting  software  engineers  to  accept  a  new  technology  is 
no  different  than  trying  to  get  any  other  group  of  people  to  change  the  way  they  work.  Studies 
have  shown  that  although  you  can  have  limited  success  by  mandating  a  change,  the  most  suc¬ 
cessful  changes  take  place  when  an  Individual  participates  in  the  change  process. 

Besides  resistance,  it  is  also  important  not  to  encourage  unrealistic  expectations.  Manage¬ 
ment  must  develop  a  clear  understanding  of  the  expected  impact  of  CASE  technology,  as  well 
as  a  time  frame  during  which  benefits  will  become  evident.  This  understanding  must  be  com¬ 
municated  to  tool  users.  In  the  past,  some  tool  adoption  efforts  have  been  oversold  as  the  so¬ 
lution  to  ail  of  an  organization’s  software  development  problems.  This  approach  has  resulted 
in  inevitable  frustrations  and  disappointments. 

Much  research  has  been  devoted  to  the  roles  people  play  in  their  organization  and  how  those 
roles  can  affect  the  adoption  process.  One  role  has  been  identified  as  being  essential  to  the 
adoption  process:  the  change  advocate.  This  person’s  job  is  to  sell  the  idea  to  management 
and  obtain  the  resources  and  commitment  to  proceed  with  the  adoption  process.  Without  this 
person,  the  adoption  cannot  take  place.  The  implementor  of  the  tool  must  recognize  himself 
as  the  change  advocate.  At  times,  he  will  be  expected  to  be  a  sociologist,  psychologist,  and  a 
software  engineer. 
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Further  reading  on  technology  transition  can  be  found  in  the  following  texts  (see  the  "Refer¬ 
ences"  section  for  further  information): 

•  Bouidin,  B.  Agents  of  Change:  Managing  the  introduction  of  Automated 
Tools. 

•  Pressman,  R.  S.  Making  Software  Engineering  Happen:  A  Guide  for 
Instituting  the  Technology. 

•  Przybylinski,  S.  &  Fowler,  P.  J.  Transferring  Software  Engineering  Tool 
Technology. 

•  Tornatzky,  L  &  Fleischer,  M.  The  Process  of  Technological  Innovation. 

3.19  Should  I  attempt  to  build  my  own  tools? 

There  have  been  severai  attempts  to  develop  proprietary  CASE  toois.  In  most  such  attempts, 
the  complexity  and  development  costs  were  severely  underestimated.  Competent  CASE  tools 
cannot  be  built  quickly  or  on  a  small  budget.  The  competing,  commercially  available  tools  often 
have  undergone  numerous  large-scale  enhancements  over  a  number  of  years. 

In  addition,  it  is  important  to  reflect  on  the  other  costs  that  an  organization  must  assume  in  de¬ 
veloping  its  own  toois.  An  organization  must  assume  complete  responsibility  for  maintenance 
of  the  tooi.  It  must  develop  its  own  training  programs  and  materials,  and  provide  personnei  to 
direct  the  training,  it  must  perform  all  of  its  own  integrations.  It  must  incorporate  (continualiy) 
all  of  the  latest  technological  advances  for  tool  integration.  In  short,  it  is  best  to  leave  CASE 
tool  development  to  the  CASE  tool  vendors. 

There  are,  however,  many  opportunities  for  organizations  to  deveiop  low-risk,  inexpensive 
toois  that  provide  support  for  the  organization’s  process,  in  many  ways,  these  tools  can  be  of 
equal  value  to  the  more  expensive  CASE  tools.  Hie  tradition  for  this  class  of  in-house  tools  is 
weil  estabiished:  organizations  have  long  built  scripts  to  automate  documentation,  code  gen¬ 
eration,  and  testing  functions.  Perhaps  one  of  the  most  useful  efforts  that  an  organization  can 
make  is  to  review  its  existing  in-house  support,  identify  holes  in  coverage,  and  buiid  local, 
small-scale  toois  to  provide  support.  White  these  tools  must  also  be  maintained,  they  are  rei- 
atively  cheap  to  build  and  support,  and  at  worst  case  can  be  thrown  away  at  little  cost. 

3.20  What  new  tool  technology  is  on  the  horizon? 

The  primary  improvements  in  tooi  technology  will  come  from  the  increasing  levels  of  integra¬ 
tion  between  tools.  Capabilities  such  as  broadcast  messaging  (offered  in  HP  SoftBench)  and 
live  links  (offered  by  FrameMaker  and  Interleaf)  will  make  new  forms  of  integration  possible. 
In  addition,  it  is  expected  that  framework  technology  will  attract  increasing  attention  as  techni¬ 
cal  hurdles  are  cleared. 

Individual  tools  will  continue  to  improve  incrementaliy.  Most  analysis  and  design  tool  vendors 
are  actively  incorporating  simulation  and  modeling  capabilities  into  their  front-end  tool  set.  In 


addition,  expert  system  technology  may  become  more  common  in  reverse  engineering  and 
application  generation. 

Tool  offerings  to  address  new  design  techniques,  such  as  object-oriented  approaches,  are  ex¬ 
pected  to  increase.  In  addition,  tightly  coupled  code  implementation  environments  currently 
available  in  the  C  community  should  become  more  common  in  the  Ada  world. 

New  government  initiatives  to  build  CASE  environments  have  the  potential  to  speed  the  tran¬ 
sition  from  current  single-point  tools  to  integrated  tool  sets.  It  is  unclear,  however,  whether  tool 
and  environment  technology  is  sufficiently  advanced  to  support  fully  integrated  environments. 
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4  Toward  a  CASE  Adoption  Strategy 


After  discussing  the  adoption  life  cycle  and  the  issues  surrounding  the  adoption  process,  it  is 
obvious  that  there  is  no  simple  route  to  selecting  and  adopting  the  best  set  of  CASE  tools  for 
a  particular  software  project.  In  light  of  the  ongoing  problems  experienced  by  organizations 
adopting  CASE  tools,  then,  it  is  hoped  that  use  of  a  well-founded  CASE  adoption  process, 
which  includes  careful  analysis  of  the  organization  and  the  tools  prior  to  actual  tool  purchase, 
will  help  maximize  the  return  on  investment  for  CASE  tools.  With  CASE  tool  adoption,  the  less 
that  is  known  about  the  adoption  effort  prior  to  the  selection  and  during  implementation,  the 
more  it  will  cost  in  time,  money,  and  satisfaction  once  problems  are  discovered. 

By  viewing  the  adoption  process  in  context  and  developing  a  tool  strategy,  the  probability  is 
higher  for  a  successfui  effort.  Although  it  is  likely  that  organizations  that  use  this  or  similar  pro¬ 
cesses  will  incur  a  significant  up-front  expense,  it  is  expected  that  the  costs  can  be  recouped 
by  more  appropriate  tool  choices  and  the  less  painful  transition  to  follow.  Even  if  an  organiza¬ 
tion  concludes  that  no  CASE  purchase  is  appropriate,  it  is  possible  that  productivity  or  quality 
gains  may  be  realized  by  careful  introspection  concerning  process,  personnel,  and  tools,  lead¬ 
ing  to  improvements  in  those  areas.  Therefore,  in  addition  to  formalizing  the  process  of  tool 
adoption,  a  useful  strategy  should  provide: 

•  a  mechanism  for  shared  exploration  of  management  and  engineer  goals, 

•  a  vehicle  for  dissemination  of  organizational  and  tool  capability, 

•  a  focus  of  commitment  for  tool  purchases,  and 

•  a  suitable  climate  for  tool  advocates  and  champions. 

The  proposed  CASE  adoption  strategy,  and  its  relationship  to  the  stages  of  the  CASE  adoption 
process  (outlined  in  Section  2),  is  defined  as  follows: 

•  Awareness  and  Commitment 

•  Assess  the  organization.  Prepare  an  organizational  assessment  report 
and  requirements  document  that  details  the  characteristics  of  personnel, 
current  technology,  process,  projects,  and  politics,  and  identifies 
organizational  needs. 

•  Selection 

•  Assess  available  technology.  Prepare  a  technology  assessment  report 
identifying  the  characteristics  of  the  Individual  tools,  tool  vendors,  and  tool 
user  experiences. 

•  Assess  the  suitability  of  the  technology  to  your  organizational  needs  and 
select  a  tool  if  appropriate.  Prepare  an  evaluation  and  selection  report 
documenting  the  suitability  of  tools,  and  develop  an  action  plan. 

•  Trial  (Implementation) 

•  Pilot  the  chosen  tool.  Prepare  a  pilot  summary  report  detailing  the 
experiences  of  the  effort,  along  with  a  set  of  lessons  learned  and  an 
implementation  plan. 
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•  Implementation  Strategy 

•  Transition  tooi  into  generai  use.  Prepare  a  list  of  lessons  learned  that  will 
facilitate  future  adoption  efforts.  Prepare  an  institutionalization  plan  that 
outlines  the  expect^  culture  changes  and  training  requirements,  and  the 
need  for  project  standards  and  effective  measurement  capabilities. 

•  Routinization 

•  Institutionalize  tool  use. 

This  proposed  CASE  adoption  strategy  is  detailed  in  Figure  4-1  and  in  the  following  sections. 
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Figure  4-1  CASE  Adoption  Strategy 
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4.1  Assess  the  Organization 

It  is  difficult  to  successfully  adopt  a  CASE  tool  without  paying  careful  attention  to  the  needs, 
expectations,  and  abilities  of  the  organization.  The  goal  of  the  organizational  assessment  is  to 
develop  an  organizational  assessment  report  and  requirements  document  that  identifies  the 
current  state  of  the  relevant  personnel,  process,  and  technology,  identifies  a  set  of  improve¬ 
ments  necessary  within  the  organization,  and  anticipates  procedural  or  cultural  roadblocks  to 
technology  enhancement.  Some  of  these  improvements  are  likely  to  involve  the  purchase  of 
software  tools,  while  others  may  involve  process  or  personnel  improvement.  The  document 
should  identify  areas  where  software  tool  support  is  adequate  and  inadequate. 

4.1.1  Evaluating  the  Organization’s  Personnel 

A  primary  aim  in  evaluating  the  organization’s  personnel  is  to  determine  whether  the  majority 
of  personnel  are  likely  to  view  a  change  in  a  positive  or  neutral  manner,  or  whether  they  will 
view  change  negatively,  or  actually  sabotage  change  efforts.  If  your  organization  is  currently 
unstable,  it  is  more  likely  that  change  will  be  unsuccessful,  since  unstable  organizations  are 
often  quicker  to  jump  on  a  bandwagon  of  change,  but  are  less  likely  to  maintain  change  over 
the  long  term.  If  your  organization  is  stable,  initial  change  may  be  more  difficult,  but  more  likely 
to  be  sustained.  With  a  more  stable  organization,  you  may  also  be  more  likely  to  anticipate 
problem  areas  and  personnel,  and  attempt  to  minimize  resistance.  Among  questions  to  be  an¬ 
swered  by  an  assessment  of  the  organization’s  personnel  are: 

•  How  will  employees  (as  a  group  and  individually}  react  to  the  introduction  of 
new  tool  technology?  Is  there  a  history  of  successful  or  unsuccessful 
changes  that  were  attempted? 

•  Are  there  leaders,  power  centers,  or  brokers  who  will  have  a  great  impact  on 
the  manner  in  which  new  tool  support  is  perceived? 

•  Is  there  a  grass  roots  movement  to  encourage  better  tools  and  technologies? 

•  How  much  education  will  be  necessary  to  orient  users  to  the  new  tool? 

•  How  stable  is  the  staff?  Is  there  a  large  turnover  rate? 

•  Are  there  any  specific  hindrances  or  aids  to  communication  in  the 
environment?  What  are  they? 

•  Are  there  any  mechanisms  and  procedures  in  place  for  change,  innovations, 
or  suggestions? 

4.1 .2  Evaluating  the  Organization’s  Technology 

The  technological  base  of  the  organization  includes  not  only  the  hardware  resources  on  which 
software  is  developed,  but  also  the  languages,  tools,  techniques,  and  targets  for  the  software. 
The  organization’s  technology  will  heavily  influence  what  tools  are  appropriate  and  available. 
The  information  gained  from  answering  this  set  of  questions  can  be  used  as  part  of  a  needs 
assessment  which  will  direct  software  purchases.  Questions  to  be  answered  include: 
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•  What  computing  resources  are  available?  What  is  the  development 
platform?  The  development  operating  system? 

•  Are  available  resources  always  adequate  to  perform  jobs  on  demand?  If  not. 
what  resources  are  the  bottleneck?  How  long  is  an  average  wait  for  the 
resource? 

•  What  software  tools  are  currently  used  in  the  organization?  What  other  tools 
exist  in  the  environment?  What  is  the  nature  of  those  tools  (e.g..  commercial, 
home  grown)? 

•  To  what  degree  are  tools  used  by  software  engineers  integrated? 

•  What  type  and  degree  of  networking  is  available  to  the  development  group? 

•  What  programming  languages  are  used? 

•  On  the  average,  what  percent  of  the  code  for  a  project  is  new?  What  percent 
is  reused?  What  percent  is  maintained? 

•  What  is  the  target  platform  for  the  project?  Are  there  extreme  constraints 
placed  on  the  software  due  to  the  target  platform?  Is  the  target  platform 
different  from  the  development  platform? 

4.1 .3  Evaluating  the  Organization’s  Process 

While  almost  all  organizations  can  benefit  from  some  type  of  improved  automation,  organiza¬ 
tions  at  different  levels  on  the  SEI  capability  maturity  model  (CMM)  may  have  different  tool 
needs.  In  addition,  the  quality  of  the  organization’s  process  will  greatly  impact  the  ability  of  that 
organization  to  incorporate  new  tools  and  to  benefit  from  the  tool  ultimately.  Questions  to  be 
answered  concerning  an  organization’s  process  include: 

•  How  well  defined  is  the  process?  How  mature  is  the  process  from  an 
organizational  standpoint? 

•  Is  the  process,  or  portions  of  the  process  amenable  to  automation?  What 
tools  are  available  to  enforce  process  and  methods  (e.g.,  bug  trackers,  CM 
tools)? 

•  What  type  of  life  cycle  or  development  model  is  used  by  the  organization 
(e.g.,  rapid  prototyping,  waterfall,  spiral)? 

•  What  is  the  organizational  model  (e.g.,  software  factory,  software  pipeline)? 

•  What  methods  do  you  use  (e.g.,  Gane  and  Sarson,  State  Charts.  Entity 
Relationship)?  How  experienced  is  the  organization  with  the  method?  What 
type  of  training  was  provided  to  staff  in  the  method?  Has  the  method  been 
tailored  or  adapted  to  your  specific  organization? 

•  Are  requirements  analysis,  specification  and  design,  coding,  and  testing 
standards  documented?  Are  they  formal,  or  informal  standards?  What 
method  is  used  to  insure  that  standards  are  met? 

•  What  metric  information  is  gathered  about  the  software  process?  How  is  it 
used?  How  long  has  it  been  gathered?  What  review  processes  are  used? 
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•  What  types  of  documentation  are  produced  during  the  sofhware  life  cycle? 

What  additional  documentation  capabilities  are  needed?  Must  a  specific 
standard,  like  DOD-STD-2167A.  be  met? 

4.1.4  Evaluating  the  Organization’s  Projects 

While  some  organizations  adopt  technology  at  an  organizational  level,  in  many  others  tech¬ 
nology  adoption  occurs  at  the  project  level.  In  fact,  even  when  tools  are  chosen  at  the  organi¬ 
zational  level,  transition  must  commonly  occur  at  the  project  level.  Questions  concerning  the 
organization's  projects  include: 

•  What  is  the  average  duration  of  a  project  In  person  months? 

•  How  are  your  projects  organized  (e.g..  dedicated  staff,  matrix  organization, 
deep  reporting  structure,  flat  reporting  structure)? 

•  What  is  the  average  size  and  range  of  ongoing  software  projects  in  terms  of 
staff? 

•  What  is  the  average  size  and  range  of  projects  in  terms  of  source  lines  of 
code  (SLOG)  or  function  points  (FP)?  How  do  you  measure  SLOC/FP? 

•  Are  there  any  special  contractor  or  government  security  requirements  that 
must  be  adhered  to?  How  do  they  affect  the  project? 

•  Does  a  group  exist  to  provide  tool  support  to  the  project? 

4.1 .5  Evaluating  the  Organization’s  Politics  and  Perceived  Needs 

The  dynamics  of  an  organization  necessitate  a  continual  evaluation  of  the  organization’s  infra¬ 
structure  and  capabilities,  including  the  practices  and  techniques  employed  within  the  organi¬ 
zation.  Questions  concerning  the  organization’s  politics  and  perceived  needs  include: 

•  How  would  your  organization’s  productivity  and  quality  compare  to  those  of 
your  competitors? 

•  What  portions  of  the  software  life  cycle  are  working  best/worst?  Are  there 
specific  portions  of  the  life  cycle  that  could  be  improved  with  new 
techniques? 

•  What  additional  documentation  production  capabilities  are  needed? 

•  Are  inter-personal  and  group  communications  adequate?  What  additional 
facilities  would  make  communication  better? 

•  Are  you  currently  collecting  software  metric  data?  What  tool  support  are  you 
using  or  do  you  expect  to  use  to  simplify  collection  of  data? 

4.2  Assess  Available  Technology 

The  goal  of  assessing  the  available  technology  is  to  develop  a  technology  assessment  report 
that  accurately  reflects  the  current  state.  This  report  should  be  far  more  than  a  listing  of  tools, 
but  rather  should  reflect  the  expected  benefits  and  costs  of  adopting  the  technology. 
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After  determining  that  a  tooi  purchase  is  appropriate  for  the  organization,  a  carefui  anaiysis 
must  be  made  of  the  tools  available.  The  number  of  tools  available  may  necessitate  the  gen¬ 
eration  of  a  two-step  assessment:  identification  of  the  full  range  of  technology,  followed  by 
careful  analysis  of  a  limited  number  of  tools.  A  coarse-grained  criteria  for  determining  whether 
a  tooi  is  appropriate  for  further  consideration  may  be  used  to  determine  which  tools  warrant 
more  detailed  analysis.  For  example,  an  organization  concerned  about  the  long-term  viability 
of  their  tool  provider  may  choose  to  grant  full  consideration  only  to  tools  with  a  relatively  large 
market  share.  [Bouldin,  1988]  suggests  that  detailed  consideration  should  be  limited  to  3  or  4 
tools. 

There  are  a  number  of  sources^  of  information  about  tools,  including  the  vendors,  and  trade 
magazines  such  as  Computerwortd.  It  is  difficult  to  develop  a  realistic  impression  of  tools  from 
these  sources,  however,  since  they  have  an  interest  in  providing  optimistic  impressions  of  tool 
technology. 

Regardless  of  the  source  of  information  about  tools,  (at  least)  three  types  of  analysis  should 
be  performed.  These  include  analysis  of  the  tool,  analysis  of  the  vendor,  and  analysis  of  the 
experiences  of  other  tool  users. 

4.2.1  Tool  Analysis 

As  previously  suggested,  it  may  be  necessary  to  perform  a  multistage  analysis  of  tools  to  limit 
the  number  of  serious  contenders.  Once  identified,  tools  under  serious  consideration  should 
be  brought  in  house  for  an  evaluation  period.  Many  vendors  will  provide  a  trial  version  of  the 
tool  to  be  used  during  the  selection  phase,  although  some  may  request  a  refundable  “deposif. 
Unwillingness  to  provide  a  trial  version  may  be  a  warning  flag  indicating  that  the  tooi  or  vendor 
is  deficient. 

A  number  of  tool  rating  scales  or  questionnaires  are  available  for  rating  tools.  While  some  of 
these  scales  provide  a  useful  starting  point  for  tool  evaluation,  others  overemphasize  the  num¬ 
ber  of  tool  features  and  appearance  of  the  user  interface.  As  a  result,  some  CASE  vendors  are 
working  furiously  to  add  new  features  that  will  attract  potential  customers  using  such  "shopping 
lists”.  However,  organizations  already  using  CASE  tools  are  often  more  concerned  about 
plans  to  improve  the  usability  of  existing  features  rather  than  adding  new  features.  In  the  end, 
it  appears  to  be  the  quality  of  existing  features  ratiier  than  the  quantity  of  what  is  promised  that 
leads  to  successful  tool  use. 

Generic  tool  rating  scales  also  do  not  reflect  the  needs  of  the  individual  organization.  However, 
based  on  the  results  of  the  organizational  assessment,  rating  scales  can  be  tailored  to  an  or¬ 
ganization  or  supplemented  by  use  of  tool  criteria  that  have  been  carefully  tailored  for  your  or- 


'  A  listing  of  CASE  pioducts  can  ba  found  in  tha  CASE  Outiook  Guidt  lo  Products  and  Sendees  (publishad  by  tha 
CASE  Consulting  Group,  Inc.,  1 1830  Karr  Parkway.  Suita  315,  Laka  Oswago,  OR  97035).  Mora  complata  tool 
avaluations  ara  availabla  from  Ovum  Ltd.  and  tha  Softwara  Tachnology  Support  Center  at  HOI  Air  Fbrca  Basa  (UT 
84056).  Ovanriaws  of  ralavant  issuas,  including  CASE  adoption,  can  ba  found  in  Ed  Yourdon’s  American  Pro¬ 
grammer  magazine  (161  Wast  86th  St  NY,  NY  10024-3411). 
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ganizational  needs.  Some  of  the  questions  particularly  dependent  on  the  unique  qualities  of 
the  organization  include: 

•  What  are  the  most  significant  aspects  (e.g.,  functions  and  features)  of  the  tool 
that  address  the  tool  and  process  requirements  of  the  organization?  What 
are  the  strong  and  weak  points? 

•  How  does  the  tool’s  performance  under  load  rate  relative  to  the  peak  demand 
expected  within  the  organization?  How  well  does  the  tool  support  the  degree 
of  simultaneous  use  expected? 

•  How  does  the  tool  handle  the  scale  of  projects  for  which  it  will  be  used?  Are 
mechanisms  provided  to  decompose  tool  data  into  subsystems?  Can  data  in 
the  subsystems  be  related? 

•  How  readily  can  the  tool  be  adapted  to  the  organization’s  environment,  or  to 
changing  requirements? 

•  How  compatible  Is  the  tool  with  existing  methods,  tools,  processes,  and 
environments? 

•  Is  the  overall  product  maturity  at  a  sufficient  level  for  the  demands  of  the 
organization?  Is  the  tool  sufficiently  robust? 

•  Is  the  tool  update  and  delivery  schedule  appropriate  for  the  organization? 

•  What  is  the  expected  time  to  proficiency  (in  months)  for  personnel  to  learn 
these  toots? 

•  What  is  the  expected  cost  (in  terms  of  dollars  and  time)  to  acquire, 
implement,  and  maintain  the  tool  (including  acquisition  costs  for  the  toot  and 
supporting  hardware  and  software,  ongoing  maintenance  costs,  and 
education-training  costs)?  Will  these  costs  jeopardize  long-term  commitment 
to  the  product? 

4.2.2  Vendor  Analysis 

As  indicated  previously,  under  novel  demands  or  when  in  support  of  large  systems,  even  the 
best  quality  tool  can  suffer  from  flaws.  The  quality  of  the  vendor  has  often  detennined  the  suc¬ 
cess  or  failure  of  a  tool  purchase.  In  addition,  since  to  gain  the  expected  benefit,  a  CASE  tool 
must  be  in  use  for  many  years,  it  is  particularly  important  that  a  CASE  tool  vendor  be  stable. 
Some  of  the  questions  to  be  considered  in  vendor  analysis  include: 

•  How  long  has  the  tool  vendor  been  in  the  CASE  tool  market? 

•  Is  the  CASE  tool  business  the  company’s  primary  business  of  the  company? 

•  What  are  the  vendor’s  annual  sales  in  dollars? 

•  Do  you  feel  that  this  vendor  is  a  stabile  entity  that  will  be  around  in  5  years? 

•  Does  this  vendor  specialize  in  support  for  your  software  engineering 
domain? 

•  How  would  you  rate  the  promptness  and  quality  of  their  support  staff? 

•  Does  the  vendor  offer  installation  and  or  education/training?  If  so,  how  would 
you  rate  these  services? 
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•  How  willing  is  the  vendor  to  customize  training  to  your  specific  needs? 

•  Does  this  vendor  have  a  market  reputation  that  you  are  aware  of?  If  so,  what 
is  the  nature  of  their  reputation? 

•  Is  the  vendor's  support  staff  located  geographically  close  to  your  location? 

4.2.3  User  Experiences  Analysis 

The  only  way  for  an  organization  to  determine  which  of  the  claims  made  by  a  vendor  are  based 
on  fact,  and  which  are  hype  is  to  attempt  to  gather  information  about  the  experiences  of  users 
of  the  tool.  There  are  a  number  of  places  where  such  information  is  potentially  available,  in¬ 
cluding  local  user  groups,  computer  bulletin  boards  devoted  to  software  engineering,  profes¬ 
sional  conferences,  and  personal  contacts  within  other  organizations.  Among  useful  questions 
are: 

•  What  issues  are  discussed  at  user  group  meetings? 

•  What  is  the  general  tenor  of  the  discussion?  Is  it  friendly,  angry,  neutral? 

•  What  is  the  vendor's  history  of  new  releases?  Are  products  released  on  or 
near  the  date  announced?  Are  new  product  releases  relatively  robust? 

•  What  quality  and  level  of  support  have  customers  experienced? 

•  What  war  stories  can  current  users  share? 

•  What  examples  of  the  tool's  use  are  available? 

•  What  hints  for  making  effective  use  of  the  tool  are  available? 

4.3  Assess  the  Suitability  of  the  Technology 

The  identification  of  available  tool  technology  is  necessary,  but  not  sufficient  to  determine  the 
suitability  of  a  tool  to  your  programming  environment.  All  tools  identified  will  have  a  set  of 
strengths  and  weaknesses  which  will  make  the  tool  more  or  less  suitable  to  your  needs.  In  or¬ 
der  to  maximize  your  chances  for  success,  you  should  compare  the  tool  needs  identified  in 
the  earlier  tool  requirements  document  with  the  idiosyncrasies  of  individual  tools. 

The  end  product  of  the  selection  process  is  a  tool  evaluation  and  selection  report  which  iden¬ 
tifies  the  candidate  tool  (or  tools)  and  specifies  which  requirements  the  tool  adequately  ad¬ 
dresses  and  which  it  does  not.  The  report  should  also  clearly  define  the  expected  impact  of 
the  tool  over  the  short  term  (during  the  adoption  process)  as  well  as  the  expected  benefit  over 
the  long  term.  An  operational  definition  of  expected  impacts  and  benefits  should  be  included 
to  facilitate  measurement  of  tool  Impact.  An  action  plan  should  be  developed  to  direct  tool  pur¬ 
chases. 


4.3.1  Evaluating  and  Selecting  the  Tools 

A  major  portion  of  the  selection  effort  may  be  spent  identifying  and  ranking  the  requirements 
(and  criteria)  for  the  tool  based  on  prior  analyse  of  organizational  needs  and  available  tech¬ 
nology.  The  rationale  for  each  of  the  requirements  should  be  carefully  recorded.  In  addition,  a 
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method  of  assessing  whether  a  toot  meets  the  criteria  should  be  defined.  The  requirements 
and  associated  rationale  will  become  useful  both  in  identifying  the  appropriateness  of  various 
tools  and  in  evaluating  the  eventual  effectiveness  of  the  tool  and  the  adoption  process.  Ideally, 
if  a  careful  job  was  done  in  developing  organizational  and  technology  assessment  documents, 
the  creation  of  selection  criteria  should  be  a  sb’aightfonvard  job. 

A  number  of  criteria  for  tool  evaluation  and  selection  have  been  published.  [Firth,  Moseiy, 
Pethia.  Roberts,  &  Wood,  1987]  includes  a  more  comprehensive  set  of  issues  to  address  in 
selecting  tools.  Appendix  B  provides  additional  pointers  to  some  of  the  available  listings  of 
tools  and  evaluations  of  specific  tools.  In  general,  tools  should  be  evaluated  for  capabilities  in 
a  number  of  both  technical  and  non-technical  areas,  including: 

•  The  compatibility  of  the  tool  with  the  capabilities  of  personnel.  While  requiring 
a  new  set  of  skills  from  personnel  may  not  necessarily  cause  a  tool  to  be 
ruled  out,  it  will  influence  training  plans  and  eventual  costs.  Groups  tasked 
with  providing  new  tool  technology  to  an  organization  have  found  that  training 
costs  can  consume  up  to  half  of  the  groups  resources. 

•  The  match  between  the  tool  and  the  organization's  perceived  needs.  A  tool 
that  does  not  meet  the  organization's  real  needs  is  bound  to  be  a 
disappointment.  Often  the  customer  holds  the  vendor  responsible  for  such 
failures,  when  in  some  cases  it  is  due  to  customer  misunderstanding  or 
unclear  definition  of  needs. 

•  The  features  provided  by  the  tool.  Obviously,  a  tool  that  does  not  provide  a 
critical  feature  will  be  less  valuable  than  one  that  does,  all  else  being  equal. 
However,  it  is  important  not  to  let  the  primary  selection  criteria  become  a 
“feature  count". 

•  The  technology  used  in  the  tool.  The  tool  technology  will  profoundly  influence 
not  only  the  degree  to  which  the  tool  will  interact  with  other  tools,  but  also  the 
number  of  years  it  will  be  usable.  This  is  not  meant  to  imply  that  only  tools 
using  the  latest  technology  are  worthy  of  consideration.  In  fact,  tools  that  use 
well  accepted  and  understood  technology  (for  example,  relational 
databases)  may  prove  to  be  more  stable  than  tools  based  on  new  but  less 
proven  technology. 

•  The  degree  of  support  provided  for  process  and  methods.  Strong  support 
does  not  equate  with  inflexible  encoding  of  process  and  methods,  however. 

The  SEI  has  accumulated  evidence  from  both  commercial  and  government 
organizations  that  rigid  encoding  of  process  and  methods  is  poorly  accepted 
by  the  users. 

•  The  degree  of  integration  within  and  external  to  the  tool.  Tools  with  good 
internal  integration  will  carry  over  a  change  in  one  portion  of  the  tool  (e.g.,  a 
data  flow  diagram)  to  another  portion  of  the  tool  (e.g.,  an  entity-relationship 
diagram).  Tools  with  strong  capabilities  for  external  integration  will  use 
consensus  standards,  and  provide  mechanisms  of  accessing  tool  data,  and 
for  controlling  the  tool  from  other  tools. 
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•  The  overall  tool  performance  and  support  for  cooperative  processing.  Many 
of  the  current  generation  of  tools  suffer  from  performance  limitations  when 
used  in  support  of  very  large  systems.  For  example,  developers  of  one  large 
environment  effort  have  not  found  a  single  COTS  tool  for  which  a  size  iimit 
could  not  be  broached  when  developing  large  systems.  High  quality  tools 
degrade  gracefully  and  provide  a  ‘Vrork  around”  at  the  system  limits  (e.g.. 
allow  reconfiguration  of  the  system  into  multiple  smaller  subsystems). 

•  The  quality  of  the  documentation  and  customer  support  available.  Types  of 
vendor  support  which  are  offered  include  tool  installation,  problem  hot  lines, 
training  sessions,  and  user’s  groups.  While  it  is  possible  to  evaluate  tool 
documentation,  it  is  much  more  difficult  to  evaluate  customer  support  prior  to 
using  the  tool  on  a  large  scale  project.  The  evaluator  must  rely  on 
impressions  gathered  from  other  tools  users  (ask  for  a  list  of  customers  and 
a  contact  at  the  customer  site),  the  vendor’s  past  track  record,  and  general 
impressions  of  vendor  quality. 

4.4  Pilot  the  Tool 

Many  organizations  transition  tools  to  their  employees  by  “decree.”  Leaders  in  the  organiza¬ 
tion  declare  that  a  tool  will  be  used  for  the  first  time  on  an  important  project,  or  will  become  the 
official  organizational  standard  as  of  a  specific  date.  This  approach  to  transition  has  led  to  a 
number  of  failures  as  inadequately  prepared  staff  struggle  with  a  tool  and  ultimately  relegate 
it  to  the  shelf. 

Before  attempting  to  finalize  a  tool  selection  or  to  use  a  tool  in  a  critical  project,  it  is  suggested 
that  the  tool  first  be  used  on  a  non-critical  path  pilot  project.  The  project  should  be  legitimate 
and  be  representative  of  the  type  of  work  for  which  the  tool  was  purchased.  It  should  be  of 
sufficient  size  to  provide  valid  lessons  learned  for  larger  projects.  The  project  should  be  head¬ 
ed  by  an  experienced  individual  recognized  as  a  leader  in  the  organization.  This  individual 
should  be  supportive  of  the  tool  effort,  but  should  also  be  viewed  as  capable  of  providing  im¬ 
partial  feedback  on  the  effort. 

4.4.1  Experiences  and  Lessons  Learned 

The  goals  of  the  pilot  adoption  are  to  identify  and  validate  procedures  and  standards  neces¬ 
sary  for  adoption  of  the  tool  by  the  more  general  organization.  The  set  of  reports  generated 
during  this  phase  may  include  a  summary  of  the  pilot  effort,  a  set  of  lessons  learned,  and  an 
implementation  plan  based  on  the  pilot  experiences.  Among  the  issues  to  be  addressed  by  a 
summary  report  on  the  pilot  adoption  effort  include: 

•  the  development  of  realistic  expectations  and  schedules  for  full-scale  tool 
Implementation. 

•  the  development  of  a  set  of  tool  experts  and  advocates  (“tool  champions”) 
who  can  seed  the  organization, 

•  the  documentation  of  the  use  of  the  tool  and  its  role  in  the  organization, 
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•  the  t£dloiing  of  the  tool,  the  methods,  and  the  organization's  process  for  most 
effective  use  of  the  tool. 

•  the  identification  of  training  needs. 

•  the  fostering  of  a  “safe"  a^'t.osphere  where  individuals  can  learn  about  the 
tool  without  excessive  pressures. 

•  the  deveiopment  of  an  organizational  plan  for  full-scale  implementation. 

•  the  development  of  standards  and  guidelines  for  tool  use, 

•  the  development  of  a  plan  to  address  anticipated  problems  with  the  tool,  the 
process,  and  the  personnel,  and 

•  the  development  of  an  implementation  plan  that  identifies  a  strategy  for  toot 
implementation,  starting  with  those  projects  most  likely  to  accept  the  tool  and 
to  experience  success,  and  gradually  transitioning  the  technology  to  projects 
less  ready  to  receive  the  tool  technology. 

4.5  Transition  the  Tool 

Prior  to  moving  toward  full-scale  implementation  of  the  tool,  the  results  of  the  pilot  effort  should 
be  evaluated  to  determine  whether  further  piloting  is  necessary.  Assuming  the  results  of  the 
pilot  suggest  that  full-scale  implementation  of  the  tool  is  possible,  an  implementation  plan  can 
be  developed. 

The  tool  can  then  be  introduced  to  selected  ‘live”  projects  based  on  the  implementation  plan. 
It  is  important  to  recognize  that  enforcing  mandates  across  the  organization  at  this  point  will 
often  lead  to  failure.  The  history  of  transition  efforts  suggests  that  complete  penetration  in  the 
organization  can  be  slow,  and  loss  of  support  at  any  stage  can  doom  the  new  technology.  The 
goals  of  the  implementation  effort,  therefore,  are  to  encourage  tool  adoption,  maintain  support, 
and  disseminate  the  tool  as  organizations  become  ready.  This  can  best  be  accomplished  by 
acknowledging  problems,  developing  a  problem-solving  climate  for  addressing  those  prob¬ 
lems,  and  rewarding  those  individuals  and  grou^  that  achieve  success  with  the  tool. 

As  in  the  pilot  phase,  one  end  product  of  the  implementation  phase  should  be  a  document  con¬ 
taining  a  set  of  lessons  learned  from  Implementing  the  tool.  Of  particular  importance  are  those 
insights  that  would  facilitate  future  adoption  efforts.  A  second  product  may  be  an  institutional¬ 
ization  plan  identifying  ongoing  support  needed  based  on  the  lessons  learned  from  adopting 
the  tool. 

4.5.1  Culture  Change 

In  addition  to  containing  a  schedule,  the  implementation  plan  should  also  discuss  the  difficulty 
of  changing  the  organization's  culture.  Cultural  change  within  the  organization  has  been  com¬ 
pared  to  the  grieving  process,  with  periods  of  disbelief,  anger,  and  (hopefully)  acceptance  of 
the  new  situation.  In  order  to  minimize  the  degree  and  duration  of  organizational  disruption, 
[Implementation  Management  Associates.  1989]  suggests  that  an  organization  must  develop 
a  systematic  process: 
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•  To  define  the  transfer  effort  by  ensuring  that  key  players  have  a  common 
view  of  why.  what  and  how. 

•  To  assess  the  organization's  history  of  technology  transition  to  identify  major 
implementation  barriers. 

•  To  plan  the  management  of  change  by  identifying  communication  and 
reinforcement  mechanisms. 

•  To  identify  key  players  and  their  roles  in  transition. 

•  To  generate  sponsorship  for  the  transition  effort. 

•  To  manage  organizational  politics  by  assessing  key  players  and  identifying 
their  potential  sources  of  resistance,  along  with  their  perceived  gain. 

•  To  assess  the  inevitable  resistance  and  identifying  tactics  to  minimize  it. 

•  To  evaluate  the  support  from  the  culture  and  planning  to  manage  it. 

•  To  assess  the  individuals  facilitating  the  change  and  developing  tactics  to 
increase  their  skill  and  motivation. 

•  To  plan,  execute,  and  monitor  the  implementation. 

4.5.2  Training 

Hopefully,  any  training  on  the  method  itself  has  sdready  been  completed.  Although  not  a  pre¬ 
ferred  solution,  it  may  be  necessary  to  combine  the  method  and  tool  training  rather  than  waste 
the  time  to  provide  training  separately.  Assessing  an  individual's  training  needs  at  this  point  is 
an  important  task.  Most  people  will  not  be  instantly  transformed  from  paper-and-pencil  users 
to  tool  "gurus",  but  they  will  respond  to  relevant  training.  True  commitment  and  expertise  may 
come  later,  after  improvements  in  productivity  and  quality  due  to  tool  use  are  evident. 

[Bouldin.  1 989]  states  that  the  selection  of  training  will  depend  on  many  factors: 

•  the  complexity  of  the  product  that  you  are  developing. 

•  the  quality  of  the  courses  that  are  commercially  available. 

•  the  amount  of  money  that  is  availidsie  in  your  organization's  budget. 

•  the  time  that  your  management  is  willing  to  allow  for  training. 

•  the  experience  level  and  interest  of  ttie  users  of  the  tool,  and 

•  your  own  interest  and  ability  In  the  area  of  teaching. 

These  factors  should  be  weighed  prior  to  selecting  the  proper  training  for  your  organization. 
The  compiexity  of  the  product  itself  will  probat^y  have  the  greatest  impact  on  the  amount  of 
training  required.  Your  own  expertise  in  this  area  should  also  not  be  discounted.  The  SEI  has 
had  significant  success  with  programs  to  "train  the  trainer.”  Instead  of  paying  for  commercial 
courses  for  a  large  group.  It  is  much  more  economical  to  train  an  in-house  instructor  and  let 
him  or  her  train  their  organization.  This  also  allows  the  instructor  to  tailor  the  course  to  include 
particulars  that  are  only  relevant  to  their  own  organization. 
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4.5.3  Project  Standards 

Imposing  standards  can  present  some  difficulties,  but  it  is  essential  to  the  success  of  the 
project.  Given  the  fact  that  almost  everything  is  built  by  more  than  one  person,  it  is  important 
to  determine  how  the  tool  is  used,  both  individually  and  by  groups.  Establishing  standards  in¬ 
cluding  naming  conventions  will  enable  a  smoother  transition  between  software  life  cycle 
phases.  Keep  in  mind  that  existing  standards  should  always  be  considered  prior  to  adopting 
a  new  standard. 

Below  is  a  list  of  standards  identified  by  [Smith,  1989]: 

•  Standards  for  using  the  tool. 

•  Naming  conventions  that  will  both  be  consistent  with  the  methodological 
needs  and  will  enable  the  use  of  the  required  analytical  reports. 

•  Standards  for  backing  up  the  database,  together  with  standards  for  data 
sharing,  and  for  locking  and  protecting  tiie  master  copy  of  the  database. 

•  Security  standards. 

•  Report  standards  for  each  stage  of  the  project's  life  cycle. 

•  Standards  for  monitoring  the  work  of  individual  analysts  and  developers.  A 
number  of  tools  enable  the  development  of  reports  on  the  work  of  each 
individual  analyst  over  specific  time  periods. 

•  Standards  and  techniques  for  interfacing  with  other  tools. 

•  Standards  for  documentation  and  document  production. 

•  Quality  assurance  standards. 

4.5.4  Evaluating  the  Effectiveness  of  CASE  Tools 

To  determine  how  effectively  a  new  CASE  tool  increases  either  productivity  or  quality,  or  both, 
the  first  step  is  to  measure  your  current  effectiveness.  Unfortunately,  few  organizations  cur¬ 
rently  employ  an  ongoing  measurement  and  process  improvement  program. 

If  you  are  attempting  to  prove  the  effectiveness  of  CASE  and  its  ability  to  improve  productivity, 
a  measurement  system  is  required.  The  measurement  must  include,  as  a  minimum,  the  ability 
to  capture  elapsed  time  and  dedicated  person  hours,  project  complexity  (possibly  as  mea¬ 
sured  by  function  points),  and  quality  as  measured  by  numbers  of  changes  to  design  and  code 
[Andrews,  1989]. 

Few  metrics  exist  for  determining  the  success  of  a  CASE  tool  adoption  effort.  In  fact,  many 
experts  believe  that  the  real  value  of  CASE  toots  lies  in  improved  quality  that  leads  to  de¬ 
creased  maintenance  costs.  This  type  of  benefit  can  be  substantial  over  a  period  of  time  be¬ 
cause  maintenance  often  accounts  for  as  much  as  70%  of  the  budget  of  a  data  processing 
organization.  It  is  important  to  recognize  that  this  potential  impact  will  not  be  felt  immediately. 

Although  a  CASE  tool  can  take  as  long  as  five  years  to  reach  its  potential,  it  may  develop  in¬ 
crementally  over  the  short  term.  For  this  reason,  regularly  measuring  performance  gains  can 
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aid  evaluation.  However,  evaluation  much  start  with  a  realistic  measurement  of  the  current  en¬ 
vironment  prior  to  tool  adoption,  and  must  maintain  consistent  data  gathering  procedures  over 
time. 


4.6  Institutionalize  Tool  Use 

Many  tools  which  have  been  purchased  and  used  for  a  period  of  time  by  the  intended  audience 
eventually  fall  into  disfavor  and  are  abandoned.  This  may  be  a  symptom  indicating  that  the  tool 
never  was  accepted  as  part  of  the  corp)orate  culture,  perhaps  because  the  organization  did  not 
recognize  the  importance  of  continued  emphasis  on  the  tool.  Even  when  a  complex  tool  has 
moved  into  general  use,  it  must  be  supported  at  a  level  far  greater  than  more  simple  tools. 
Suggestions  for  continued  support  of  a  tool  that  may  help  routinize  Its  use  Include: 

•  Continue  support  for  ongoing  training.  Between  new  revisions  of  the  tool  and 
new  staff,  it  is  likely  that  training  nee^s  will  continue  indefinitely. 

•  Develop  and  implement  policies  for  handling  tool  updates.  Installation 
procedures  and  responsibilities  must  be  clearly  defined.  Check-out 
procedures  must  be  identified  to  determine  whether  a  new  version  meets 
standards  for  quality,  as  should  upgrade  procedures  to  transform  existing 
tool  databases  to  new  formats.  Potentially,  the  configuration  of  tool  versions 
and  the  supporting  environment  (other  tools,  the  operating  system,  etc.)  must 
be  managed. 

•  Mechanisms  should  be  established  for  internal  sharing  of  experiences. 

Potentially  valuable  devices  include  bulletin  boards,  news  letters,  and  reuse 
libraries. 

•  Mechanisms  should  be  sought  out  for  the  sharing  of  experiences  externally. 

These  may  include  user  groups,  workshops,  and  published  articles. 

•  The  relationship  with  the  vendor  should  be  cultivated  in  order  to  stay  abreast 
of  plans  and  to  insure  that  the  vendor  addresses  feedback  from  your 
organization. 

•  Mechanisms  to  continually  promote  tool  use  should  be  developed.  These 
may  include  recognition  for  expert  use  and  the  establishment  of  a  career  path 
for  individuals  particularly  interested  In  environments  and  tools. 

•  Continual  assessment  of  software  quality  and  productivity  is  essential  to 
identify  that  you  are  in  fact  improving,  and  to  provide  early  notification  if  your 
strategy  is  failing. 
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5  Conclusion 


It  is  likely  that  more  than  half  of  all  CASE  tools  purchased  are  no  longer  in  use.  Besides  the 
cost  of  the  tool  itself,  this  wasted  expense  may  also  include  hardware  costs,  training  costs, 
and  lost  employee  productivity. 

In  spite  of  what  some  vendors  will  tell  you  about  the  ease  of  adopting  their  tool,  no  one  can 
guarantee  your  success.  To  a  great  extent,  both  the  quantity  and  quality  of  success  will  de¬ 
pend  on  how  well  your  organization  manages  the  adoption  process. 

There  is  no  simple  route  to  selecting  and  adopting  the  best  set  of  CASE  tools  for  your  organi¬ 
zation.  However,  by  viewing  CASE  tool  adoption  in  the  larger  context  of  organizational  needs, 
and  by  developing  a  tool  strategy  as  part  of  a  larger  organizational  improvement  strategy,  you 
increase  the  probability  for  a  successful  effort. 

A  good  analogy  for  the  process  of  CASE  tool  adoption  can  be  found  in  the  software  develop¬ 
ment  process.  Careful  definition  of  requirements  is  essential.  If  an  error  is  discovered  during 
the  requirements  phase,  it  is  relatively  inexpensive  to  fix.  The  longer  the  error  remains  unde¬ 
tected,  the  more  it  will  cost  to  correct.  With  CASE  tool  adoption,  the  less  that  is  known  about 
the  adoption  effort  prior  to  the  selection  and  during  implementation,  the  more  it  will  cost  in  time, 
money,  and  satisfaction  once  problems  are  discovered. 
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Appendix  A 

Acronyms  Used  in  This  Guide 

Ada 

Department  of  Defense  programming  language 

AiX 

International  Business  Machine’s  Unix  operating  system 

ASCII 

American  standard  code  for  information  exchange 

CASE 

computer-aided  software  engineering 

CDIF 

CASE  data  interchange  format 

CM 

configuration  management 

CMM 

Capability  Maturity  Model 

COTS 

Commercial  off-the-shelf  software 

CPU 

computer  processing  unit 

DoD 

Department  of  Defense 

ECMA 

European  Computer  Manufacturers’  Association 

FP 

function  points 

MIS 

management  information  systems 

MOTIF 

Open  Software  Foundation’s  graphical  user  interface 

PCTE 

portable  common  tool  environment 

POSIX 

portable  operating  system  interface 

ROI 

return  on  Investment 

SEI 

Software  Engineering  Institute 

SLOC 

source  line  of  code 

STD 

standard 
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Appendix  B  CASE  Adoption  Resources 

The  following  tables  provide  a  useful  set  of  pointers  to  sources  of  information  on  Computer 
Aided  Software  Engineering  (CASE)  tools.  This  information,  whiie  not  all-inclusive,  does  rep¬ 
resents  a  significant  cross  section  of  the  type  of  information  that  is  availabie  from  commerciai 
and  government  sectors. 

Listed  beiow  is  a  summary  of  the  foilowing  eight  tabies: 

Table  B-1 :  U.S.  Government  CASE  Information  Sources 

Table  B-2:  CASE  Industry  Specific  Reports/Directories 

Table  B-3:  CASE  industry  Specific  Magazine-Based  Buyer's  Guides 

Table  B-4:  General  Software  Industry  Reports/Directories 

Table  B-5:  Consulting  Groups/Conferences 

Table  B-6:  CASE  Industry  Newsletters 

Table  B-7:  CASE  Trade  Shows 

Table  B-8:  CASE  User  Groups 
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Table  B-1 :  U.S.  Government  CASE  Information  Sources 


QSACASEbaea 

Judith  Andrews 

CASE  database  of  vendors/ 

GSAAJSDfT 

tools  and  government  users/ 

5203  Leesburg  Pike 

Suite  tt08 

Falls  Church,  VA2204t 

(7«175fra5a2 _ 

evaluators 

STSCCASEDatalMM/ 
Toolbox  PC 


Air  Force  Software  Techr«logy  Support  Certter 

Reuel  Alder 

CX>AL(yTISAC 

Air  Force  Software  Technology  Support  Center 

HiUAFB.UT840S6 

AV458-804S 


»lso  conaa  tor 

Joirtt  Softrrtft  Support  Cort/ertnco 
Apni4-19,  1991 
Salt  Lako  City.  UT 
Sponsored  by  HO  USAF/SC 
and  the  Pentagon 


Systema  Engiiteerlng  Toole 
lor  Computer-Aided  Oeeign 
of  Ultra-Reliable  Syatems 


Revlawe  of  Selected  Syatem  and 
Software  Toole  for  Strategic 

Oafenae 


Evaluation  of  Exlatlng  CASE  Toole 
for  Tactical  Embedded  Syatem 


Software  Engineering 
TOOLS  CATALOG 


Appendix  A,  Table  A-tO  CASE  Tools 
BATTELLE 

Tactical  Technology  Center 
SOS  King  Avenue 
Columbus,  OH 
Sponsorsed  by  OARPA 

Available  thru  Defense  Technical  Information  Center 


Institute  for  Defense  Analyses 
IDA  Paper  p.2177 
Alexandria,  VA 

Defense  Technical  Information  Center 
Session  Number  ADA228  962 


CECOM  Center  for  Software  Engineering 
USArmyCECOM 
AMSEL-RD-SE-AST-SE 
Fl  Monmouih,NJ  07703 


The  Aerospace  Corporation 

ATR-OOeO(8tt5)-1 

El  Segundo,  CA  00245-4601 


Covers  Software  through  Pictures, 
Teamwork,  TAGS.Auk><S.  OCOS, 
HDD,  Statement,  Refine,  Destg/V 
fXP,  001,  Foresight,  Virtual  Soittware 
Factory  SAdagen 


Covers  Teamwork,  Pro*4od,  £POS, 
Software  through  Pictures,  Sraiemaie, 
Autocode,  Model,  CCC,  Foresight, 
TASuperCASE 


Covers  Anaatol,  OaiaVfiewe,  Design 
Aid,  Doorrtiter,  Exoelerattr,  FDM, 
NexpenObtect,  PIES.  P-NUT, 
PormToois,  Software  Site  Esiimaior, 
Srmware  through  Pictures,  Statemate, 
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Table  B-2:  CASE  Industry  Specific  Reports/Directories 


ACMSK3SOFT 

Project  SYTI 

AnAnnouitdCASB  Biblography 

rVa 

Software  Engineering  Note* 

Dept  of  Computer  Scienoa 

vol  l5noi 

University  ot  JyvSsftylA 

'Jan  1990  Page  70 

Saminaarinkatu  15 

SF-40100  JyvftskylA 

FINLAND 

BIS  CAP  Inleitiallonal 

POB68 

Newtonvilla.  MA02160 

18171893-9130 

knptemonting  CASS:  A  Uanagm’s  Guidt 

$595 

CASE  Cenaeitium 

Center  tor  Study  o(  Data  Processing 

CASE  Studios  AnnoiaMt  Solhiiarf^sMns  B9>legraplV 

unknown 

Washington  University 

(over  400  dtatioru  in  20  categories) 

Campus  Box  1141 

Prince  Hall  224 

One  Brooking  Drive 

Sl  Louis.  MO  631 30^t809 

13141889-4792 

CASE  Studies  Consortium  MIS  Mjsoy  Survey 

unknown 

CASE  Censuillng 

11830  S.W.  Karr  Parkway 

An  Introduction  to  CASE:  The  Best  ot  CASE  OUTLOOK 

$225 

Qroup,  Inc. 

Suite  315 

Annual  CASE  Direclory 

$195 

CASE  Reeaareh 

15S10eihAve.  N.E. 

The  Strategie  Inpea  of  CASS'-  Volurtte  1  Video 

$125 

Suile  210 

The  Strategic  mpaaol  CASS' -Volume  II  Video 

$225 

Bellevue.  WA  08004 

Annual  CASE  Survey  1968 

$150 

CASEBulleins 

$125 

Note;  CASE  Research  recently 

CASE  in  Practice  reports 

$225 

merged  with  Ernst  A  Ybung 

ProduaProSlea 

$225 

For  more  intormation  contact 

Ernst  &  Young's  Center 

tor  Intormaiton  Technology  Strategy 

18171742-2500 

The  Second  Annual  ReportonCASE 

$595 

German  National 

Western  US  Oflloe 

The  CASE  Products  VO 

Frae 

Reaaareh  Canter 

1942  Universiiy  Avenue 

(Madmosh  HyperCard-based  Public  Domain  Database) 

For  Computer  Science 

Berkeley.  CA  94704 

available  on  Intemot.  anonomous  FTP 

Ovum  Ltd 

7  Raihbona  Street 

Analysis  Techniques  lorCASE:aDetaiedEvaluallen 

$995 

London  W1P1AF 

CASE  Analyst  Wotiihenches:  a  DetadedEvaluaion 

$995 

England 

CASE:  die  Nest  Steps 

$995 

Real-dme  CASE:  dte  mtsgradon  Batde 

$995 

P-Cuba  Corporation 

01 5  Kings  Canyon  Road 

Brea.  CA  92621 

17141990-3189 

CASEbase  (a  PC-based  CASE  database) 

unknown 

ForeaKe  Syatama 

For  intormation  contact; 

Digital  Consulting.  Inc 

204  Andover  Street 

Andover.  MA  01810 

15081470-3880 

1090  CASE  Evaluation  Report 

unknown 

Software  Producthrlly 

POB204-MO 

CASE  Trends  Industry  Guide 

$179 

Group,  Inc. 

Shrewbury.  MA01545-0294 
<5081842-4500 _ 
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Table  B*3:  CASE  Industry  Specific  Magazine-Based  Buyer's  Guides 


Compular  Oacitlom 
Computorwortd 


GovwtmanI  Cemputar  N«w« 
IEEE  SoHunra 


I  ■ . .  rH  111  ii  *  i'iTT<rE*iM  r*  r 


PCWMk 

PCWMk 

WMk _ 


SoHwara  Magazlna 


I  I  rTTTi '*  riTM  un 


1  Oct  88 
27  Mar  89 


Change  oonni  meats  CASE 
CASE  software  products 


21  Nov  88 

p81(7) 

24JUI88 

p37(7) 

toack 


CASE  loois:  Unely  assistance  tor  PC-based  software  designers 
Tools  Fair 


f  iP/JI  I-*.  .•'s’a 


Education  dealing  the  way  for  implamenting  CASE 
CASE  spurs  die  re-engineering  of  users' hearts  and  minds 


1 0ct 90  I  P41(10)  \Thefao9isonfoflools^bMlolBMr9posiloty 


IliTT^w^'.Y  / 


Table  B-4:  General  Software  Industry  Reports/Directories 
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Table  B>5:  Consulting  Groups/Conferences 


Digital  Conaulllng,  Ine. 

204  Andover  Street 

Andover,  MA  01810 

(508)470-3880 

AocahnUngApfieeatont  Oeteispmanr  ItJsing  HAD,  CASS...) 
Analyzing  Uaer  Raquhamanm 

Capara  Jonaa:  SoKwara  Uaasuramant  8  Eatimation 

CASE:  Tha  Nazi  Ganaratan 

Compuiar-Aidad  Sottwafa  Enginaaring  Symposium 

Data  ModaSng  and  CASE 

Evaluating  CASE  Tools 

SUsAD/Cyda 

Imolamenlino  Soflwata  Enoinoarino  and  CASE 

Extandad  Intalllganca,  Inc. 

(Associated  with  Or.  Carma  McClure) 

25  East  Washington  Street 

Suite  600 

Chic^.  IL  60602 

13121 348-7090 

CASE  lofdta  1990a 

Ra-Enginaaring,  Raposilotiaa,  Raua^tSty 

Software  Oevelopmont  Coneepta 
(Associated  with  Or.  Paul  Ward) 

424  West  End  Avenue 

Suite  11E 

NewYork,  NY  10024 
12121362-1391 _ 
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